[JBoss JIRA] (TEIID-2649) NoClassDefFoundError when trying to run adminshell
by Van Halbert (JIRA)
Van Halbert created TEIID-2649:
----------------------------------
Summary: NoClassDefFoundError when trying to run adminshell
Key: TEIID-2649
URL: https://issues.jboss.org/browse/TEIID-2649
Project: Teiid
Issue Type: Bug
Components: Tools
Affects Versions: 8.4.1
Reporter: Van Halbert
Assignee: Steven Hawkins
Priority: Blocker
adminshell is throwing the following exception when trying to be run:
Exception in thread "main" java.lang.NoClassDefFoundError: jline/History
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
at java.lang.Class.getDeclaredMethods(Class.java:1845)
at org.codehaus.groovy.reflection.CachedClass$3$1.run(CachedClass.java:83)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:80)
at org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:78)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
at org.codehaus.groovy.reflection.CachedClass.getMethods(CachedClass.java:249)
at groovy.lang.MetaClassImpl.populateMethods(MetaClassImpl.java:341)
at groovy.lang.MetaClassImpl.fillMethodIndeMetaClassImpl.java:291)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2912)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:210)
at org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:701)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallConstructorSite(CallSiteArray.java:69)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:52)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:192)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:200)
at org.codehaus.groovy.tools.shell.Main.main(Main.groovy:124)
at org.teiid.adminshell.GroovyAdminShell.main(GroovyAdminShell.java:30)
Caused by: java.lang.ClassNotFoundException: jline.History
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 23 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2584:
-------------------------------------
I was going to add, stop running the "start" triggers always by adding "isStartInProgress" call, thus making them symmetric.
About Status table memory resident, we can do that when the contents are survive a node/cluster restart, otherwise we could have done that now. Since the query is in "wait" mode anyways it did not concern me that we are making another database call.
Since "load" and "update" calls are not part of the user query, and matview updates are to the single source "XA" transactions should not be concern right? Especially when we introduce the separate connection for execution of these calls.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-2584 at 9/5/13 8:19 AM:
---------------------------------------------------------------
I think for now I'm going to move the start/stop stuff off of the metadata api and just make it a concern of the materialization manager. I do see that the tokenize method does handling escaping, so that's not a concern.
I'm also going to remove the onErrorAction from the status table and just rely on the one that's on the metadata and when it is set to null/ignore will allow the optimizer to omit the criteria check altogether. Later if we refine the status logic to be something that we hold more or less in memory, then we can retarget the logic of the mvstatus function and not incur the database read. I'll also tweak the mvstatus definition to use the TeiidFunction annotation, which makes it easier to define that the old style SystemSource logic and mark it as non-deterministic so that it will cause the subquery to be reevaluated.
Another concern is the approach of using Teiid procedures with XA transactions against sources that require a commit when executing DDL - such as Oracle. I believe that they will simply not allow DDL under an XA transaction. At least for Oracle the caveat is that the scripts may just need to be a little more complicated and use an anonymous subtransaction.
was (Author: shawkins):
I think for now I'm going to move the start/stop stuff off of the metadata api and just make it a concern of the materialization manager. I do see that the tokenize method does handling escaping, so that's not a concern.
I'm also going to remove the onErrorAction from the status table and just rely on the one that's on the metadata and when it is set to null/ignore will allow the optimizer to omit the criteria check altogether. Later if we refine the status logic to be something that we hold more or less in memory, then we can retarget the logic of the mvstatus function and not incur the database read. I'll also tweak the mvstatus definition to use the TeiidFunction annotation, which makes it easier to define that the old style SystemSource logic and mark it as non-deterministic so that it will cause the subquery to be reevaluated.
Another concern is the approach of using Teiid procedures with XA transactions against sources that require a commit when executing DDL - such as Oracle. I believe that they will simply not allow DDL under an XA transaction.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2584:
---------------------------------------
I think for now I'm going to move the start/stop stuff off of the metadata api and just make it a concern of the materialization manager. I do see that the tokenize method does handling escaping, so that's not a concern.
I'm also going to remove the onErrorAction from the status table and just rely on the one that's on the metadata and when it is set to null/ignore will allow the optimizer to omit the criteria check altogether. Later if we refine the status logic to be something that we hold more or less in memory, then we can retarget the logic of the mvstatus function and not incur the database read. I'll also tweak the mvstatus definition to use the TeiidFunction annotation, which makes it easier to define that the old style SystemSource logic and mark it as non-deterministic so that it will cause the subquery to be reevaluated.
Another concern is the approach of using Teiid procedures with XA transactions against sources that require a commit when executing DDL - such as Oracle. I believe that they will simply not allow DDL under an XA transaction.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2584:
-------------------------------------
>It seems like the events are asymetrical - one is basically for every vdb startup and the other is for once the vdb is removed. Who then is responsible for the removal of the materialization table / staging table? Or are you leaving that off to avoid complications with sharing the mat view across redeployments.
Yes, since there was no real way to detect if the vdb is deployed first time vs restart it is being executed every time, I could not think of a way to differentiate between them. By providing hooks at the different events, I would like defer those cleaning activities to user such that they can be used in sharing scenarios. At first, I had script automatically deleting them, then with scoping I opted to this option. Can you think any way to limit to one execution? I thought may be metadata caching, or may be I can ask AS for deployment artifact time to figure out it is new deploy vs old.
>How will permissioning work with stuff that is executed by the materialization manager? That is what expectations need to be satisfied so that DDL/native queries can be executed - but not necessarily requiring exposing that as general user functionality.
I was thinking, we should extend the vdb.xml's source element to take a optional "admin-connection-jndi-name" attribute that defines a separate connection, where through some mechanism (hint or execution property) we can instruct ConnectionManager to use that connection instead of regular "connection-jndi-name".
>It seems like we may also have to tweak the before/after load scripts as not all dbs support executing multiple statements together.
Yes, I will fix it. Same may be true, when "load" script is present. User can optionally specify "load" script too.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2584:
---------------------------------------
It seems like the events are asymetrical - one is basically for every vdb startup and the other is for once the vdb is removed. Who then is responsible for the removal of the materialization table / staging table? Or are you leaving that off to avoid complications with sharing the mat view across redeployments.
How will permissioning work with stuff that is executed by the materialization manager? That is what expectations need to be satisfied so that DDL/native queries can be executed - but not necessarily requiring exposing that as general user functionality.
It seems like we may also have to tweak the before/after load scripts as not all dbs support executing multiple statements together.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2584:
-------------------------------------
Yes, startup/shutdown needs to be elevated, we will do that as another issue, as there are some issues with declaring the DML for them
in vdb.xml and figuring out difference between startup/re-deploy etc.
This is the sample I have been testing with
{code:lang=XML}
<metadata type="DDL"><![CDATA[
CREATE VIEW actor (
actor_id integer,
first_name varchar(45) NOT NULL,
last_name varchar(45) NOT NULL,
last_update timestamp NOT NULL
) OPTIONS (MATERIALIZED 'TRUE', UPDATABLE 'TRUE',
MATERIALIZED_TABLE 'pg.public.mat_actor',
"teiid_rel:MATERIALIZED_STAGE_TABLE" 'pg.public.mat_actor_staging',
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_STATUS_TABLE" 'pg.public.status',
"teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute pg.native(''truncate table mat_actor_staging'');',
"teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute pg.native(''ALTER TABLE mat_actor RENAME TO mat_actor_temp;ALTER TABLE mat_actor_staging RENAME TO mat_actor;ALTER TABLE mat_actor_temp RENAME TO mat_actor_staging;'')',
"teiid_rel:MATVIEW_SHARE_SCOPE" 'NONE',
"teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION',
"teiid_rel:ON_VDB_DROP_SCRIPT" 'DELETE FROM pg.public.status WHERE Name=''actor'' AND schemaname = ''sakila''')
AS /*+ cache(ttl:180000)*/SELECT actor_id, first_name, last_name, last_update from pg."public".actor;
]]>
</metadata>
{code}
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2584:
---------------------------------------
> Start up/Shutdown hooks so that Teiid can clean up the status table when deployed or undeployed.
A couple of thoughts on that then. We should either elevate the concept of a start/stop action beyond just the materialization use or the materialization manager should directly scan for appropriate metadata entries on start/stop and remove the MetadataStore/MetadataFactory components (which need tweaked as a set method is used on the MetadataStore which means that we won't properly merge across all schemas). But I'm still unsure as to what the scripts would look like. You have ; parsing (however ; in literals/comments would be a problem) so you are expecting multiple statements - what would some examples be?
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2584:
-------------------------------------
1) Start up/Shutdown hooks so that Teiid can clean up the status table when deployed or undeployed.
2) Since there is always a row in status table concerning the view in question, the existence of the row irrespective of value (even null) evaluating to true, where a false is expected. So, this is the alternative I found with qualified comparison, but open to change to make it correct.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2584:
---------------------------------------
Also I'm not sure I follow you on the use of EXISTS vs. quantified comparison. Unless you are introducing another on error action of "no rows", then you don't have to check the return value of the function.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Beta3
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months