I'm using Github (https://github.com/connecta-solutions/connecta-framework) and Travis (https://travis-ci.org/connecta-solutions/connecta-framework) to host and build an open-source project of mine, that uses Apache Metamodel as one of its dependencies.
I'm not making many unit tests, but the log generated by a specific test that uses a feature from Metamodel is gigantic, and passes the 4MB log size determined by Travis, so it quits the build with the following message:
The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
The job has been terminated
Most of the log I get are unimportant debug messages from a Comparator inside Metamodel, which usually gives the following output:
18:18:23.519 [main] DEBUG o.a.metamodel.util.ObjectComparator - compare(Sul,50)
18:18:23.519 [main] INFO o.a.metamodel.util.ObjectComparator - Using ToStringComparator because no apparent better comparison method could be found
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - SUM(csv_cities.csv.vendas).hashCode()
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is a regular object, returning hashCode
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is a regular object, returning hashCode
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is a regular object, returning hashCode
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG o.a.metamodel.util.EqualsBuilder - append(false)
18:18:23.519 [main] DEBUG o.a.metamodel.util.EqualsBuilder - append(true)
18:18:23.519 [main] DEBUG o.a.metamodel.util.ObjectComparator - compare(Sul,50)
18:18:23.519 [main] INFO o.a.metamodel.util.ObjectComparator - Using ToStringComparator because no apparent better comparison method could be found
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - SUM(csv_cities.csv.vendas).hashCode()
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is a regular object, returning hashCode
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is a regular object, returning hashCode
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is a regular object, returning hashCode
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG org.apache.metamodel.util.BaseObject - obj is null, returning constant
18:18:23.519 [main] DEBUG o.a.metamodel.util.EqualsBuilder - append(false)
18:18:23.519 [main] DEBUG o.a.metamodel.util.EqualsBuilder - append(true)
The ideal situation was that Travis somehow accepted this, as unimportant log can quickly become important when you face a problem. Anyway, I tried to reduce the log level to get only warning and errors, passing the argument for log4j to do so, like this:
mvn test -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
What I later realized was that Logback was the log engine for this Metamodel feature, and I discovered that it's not possible to reduce the loglevel of Logback with a parameter like you can in Log4j. Yet I didn't find a way to remove logback and use the standard logger I'm using for the whole application, then I could control what level it tries to output a message.
Is this the last word of Travis CI? Isn't there a way to keep all the log, even if does pass the 4MB log size?
If it doesn't, how can I remove only this unimportant part of the log inside Metamodel?
Keeping the whole log in dev mode, and just omitting it on a Travis build would be perfect, but if I can't, I can omit this part of the log forever, if there's no choice.
Try to adjust the logging of specific namespace (e.g. whole org.apache.metamodel) via log4j.xml configuration file placed in src/test/resources of your project.
An example can be found in the metamodel codebase: https://github.com/apache/metamodel/blob/060884c17d1c5c35348d2cb675bed1c404013579/jdbc/src/test/resources/log4j.xml#L12
Related
My spring-boot app starts a Camel route that consumes from a Kafka-enabled Azure event hub. Immediately after the message that the Application has started, this message is logged: "INFO o.a.camel.spring.SpringCamelContext - Apache Camel 2.24.0 (CamelContext: camel-1) is shutting down".
Then any in-flight exchanges (if they exist) are successfully processed by the Camel route, and eventually the route is shutdown (gracefully), which also terminates the app.
No error messages are shown, nothing seems to be wrong, except that the shutdown is initiated automatically right after the application starts....
Any idea why this happens ?
I have played around with the timeouts for Kafka, but there's no change in behavior.
I have set the logging level to TRACE, but still I don't see why shutdown is initiated.
Among others, I use these libraries: spring-boot-starter, spring-boot-starter-web, azure-servicebus-spring-boot-starter, camel-kafka, camel-spring-boot-starter, camel-undertow-starter
This is how the route starts:
from("kafka:dummytopic?brokers=dummy.servicebus.windows.net:9093&topic={{event.hubs.hub.magento}}&groupId={{event.hubs.consumer-group}}"
+ "&consumersCount=1"
+ "&autoOffsetReset=latest"
+ "&saslMechanism=PLAIN"
+ "&securityProtocol=SASL_SSL"
+ "&sslProtocol=TLSv1.2"
+ "&sslEnabledProtocols=TLSv1.2"
+ "&sslEndpointAlgorithm=HTTPS"
+ "&saslJaasConfig=" + saslJaasConfig
+ "&autoCommitEnable=true")
.....
Normally the route should keep running and polling the kafka Event Hub for events (and process them when they are available).
Instead, it initiates shutdown immediately (still successfully processing any in-flight exchanges) - it simply shuts down gracefully. No error messages.
Any help is appreciated!
PS: this is an extract from the trace log:
15:01:40.867 [main] INFO c.i.s.n.NotificationMicroserviceApplication - Started NotificationMicroserviceApplication in 10.516 seconds (JVM running for 14.643)
15:01:40.868 [main] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'camelContext'
15:01:40.868 [main] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'springApplicationAdminRegistrar'
15:01:40.868 [main] DEBUG o.a.camel.spring.SpringCamelContext - onApplicationEvent: org.springframework.boot.context.event.ApplicationStartedEvent[source=org.springframework.boot.SpringApplication#22aefae0]
15:01:40.870 [main] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'camelContext'
15:01:40.870 [main] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'springApplicationAdminRegistrar'
15:01:40.870 [main] DEBUG o.a.camel.spring.SpringCamelContext - onApplicationEvent: org.springframework.boot.context.event.ApplicationReadyEvent[source=org.springframework.boot.SpringApplication#22aefae0]
15:01:40.872 [Thread-37] DEBUG o.s.c.a.AnnotationConfigApplicationContext - Closing org.springframework.context.annotation.AnnotationConfigApplicationContext#2cd2a21f, started on Thu Jun 06 15:01:31 EEST 2019
15:01:40.873 [Thread-37] TRACE o.s.c.e.PropertySourcesPropertyResolver - Searching for key 'spring.liveBeansView.mbeanDomain' in PropertySource 'configurationProperties'
15:01:40.873 [Thread-37] TRACE o.s.c.e.PropertySourcesPropertyResolver - Searching for key 'spring.liveBeansView.mbeanDomain' in PropertySource 'systemProperties'
15:01:40.873 [Thread-37] DEBUG o.s.c.e.PropertySourcesPropertyResolver - Found key 'spring.liveBeansView.mbeanDomain' in PropertySource 'systemProperties' with value of type String
15:01:40.874 [Thread-37] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'camelContext'
15:01:40.874 [Thread-37] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'springApplicationAdminRegistrar'
15:01:40.875 [Thread-37] DEBUG o.a.camel.spring.SpringCamelContext - onApplicationEvent: org.springframework.context.event.ContextClosedEvent[source=org.springframework.context.annotation.AnnotationConfigApplicationContext#2cd2a21f, started on Thu Jun 06 15:01:31 EEST 2019]
15:01:40.877 [Thread-37] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'camelContext'
15:01:40.877 [Thread-37] TRACE o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'lifecycleProcessor'
15:01:40.879 [Thread-37] DEBUG o.s.c.s.DefaultLifecycleProcessor - Stopping beans in phase 2147483647
15:01:40.879 [Thread-37] TRACE o.s.c.s.DefaultLifecycleProcessor - Stopping bean 'camelContext' of type [org.apache.camel.spring.SpringCamelContext]
15:01:40.879 [Thread-37] INFO o.a.camel.spring.SpringCamelContext - Apache Camel 2.24.0 (CamelContext: camel-1) is shutting down
15:01:40.879 [Thread-37] TRACE org.apache.camel.util.ServiceHelper - Stopping service org.apache.camel.impl.DefaultRouteController#108b121f
15:01:40.879 [Thread-37] TRACE org.apache.camel.util.ServiceHelper - Shutting down service org.apache.camel.impl.DefaultRouteController#108b121f
15:01:40.879 [Thread-37] TRACE o.a.camel.support.ServiceSupport - Service already stopped
15:01:40.880 [Thread-37] INFO o.a.c.impl.DefaultShutdownStrategy - Starting to graceful shutdown 1 routes (timeout 300 seconds)
15:01:40.880 [Thread-37] TRACE o.a.c.m.DefaultManagementLifecycleStrategy - Checking whether to register org.apache.camel.util.concurrent.RejectableThreadPoolExecutor#11ee4d34[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0][ShutdownTask] from route: null
15:01:40.880 [Thread-37] DEBUG o.a.c.i.DefaultExecutorServiceManager - Created new ThreadPool for source: org.apache.camel.impl.DefaultShutdownStrategy#58b97c15 with name: ShutdownTask. -> org.apache.camel.util.concurrent.RejectableThreadPoolExecutor#11ee4d34[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0][ShutdownTask]
15:01:41.073 [Thread-37] TRACE o.a.c.u.c.CamelThreadFactory - Created thread[Camel (camel-1) thread #2 - ShutdownTask] -> Thread[Camel (camel-1) thread #2 - ShutdownTask,5,main]
15:01:41.075 [Camel (camel-1) thread #2 - ShutdownTask] DEBUG o.a.c.impl.DefaultShutdownStrategy - There are 1 routes to shutdown
15:01:41.075 [Camel (camel-1) thread #2 - ShutdownTask] TRACE o.a.c.impl.DefaultShutdownStrategy - Shutting down route: routeEventHub with options [Default,CompleteCurrentTaskOnly]
You can see that at 15:01:40.872 it starts closing things down...
I had the same problem, for me case the solution it was add the next depency into pom file.
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>
There is no thread that keeps the application alive. That's why it immediately shutsdown.
You may want to add spring-boot-starter-web to have a web container that is running or you could have a loop in our main class that prevents the shutdown.
I would go for the web container. So you could also add the actuator framework with some diagnostic information.
This is related to spring version upgrade.
The problem described is related to conflicts between different Maven dependencies. I've had the same problem while trying to use the latest version of Spring Boot with Apache Camel.
After analyzing the dependency tree, it turned out that the version of spring-webmvc was 5.2.9, while all other spring dependencies were of version 5.2.8.
I have solved the problem by using a newer version of camel-spring-boot-dependencies (3.6.0)
Eventually, this solution worked:
#Slf4j
#SpringBootApplication
public class NotificationMicroserviceApplication implements CommandLineRunner {
public static void main(String[] args) {
SpringApplication.run(NotificationMicroserviceApplication.class, args);
}
#Override
public void run(String... args) throws Exception {
log.info("You can press Ctrl+C anytime to shutdown application");
Thread.currentThread().join();
}
}
recently I'm trying to call a REST-service, published over Apache-CXF. Everything is embedded in an Equinox 3.11.0 with Jetty 9.4.1.
Container starts Jetty, configured for HTTP/2:
[main] INFO org.eclipse.jetty.server.Server - jetty-9.4.1.v20170120
[main] INFO org.eclipse.jetty.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler#6f89f665{/,jar:file:///C:/workspaces/com.ebase.eox/cnf/generated/fw/org.eclipse.osgi/12/0/bundleFile!/,AVAILABLE}
[main] INFO org.eclipse.jetty.server.AbstractConnector - Started ServerConnector#187eb9a8{HTTP/1.1,[http/1.1, h2c]}{0.0.0.0:8080}
[main] INFO org.eclipse.jetty.util.ssl.SslContextFactory - x509=X509#1517f633(jetty,h=[],w=[]) for SslContextFactory#4fe01803(bundleentry://12.fwk1276261147/jettyhome/etc/keystore,bundleentry://12.fwk1276261147/jettyhome/etc/keystore)
[main] INFO org.eclipse.jetty.server.AbstractConnector - Started ServerConnector#3015db78{SSL,[ssl, alpn, h2, http/1.1]}{0.0.0.0:8443}
Wenn i call a REST-Service over https/ssl i get an error:
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at org.eclipse.jetty.http.PreEncodedHttpField.putTo(PreEncodedHttpField.java:119)
at org.eclipse.jetty.http2.hpack.HpackEncoder.encode(HpackEncoder.java:289)
at org.eclipse.jetty.http2.hpack.HpackEncoder.encode(HpackEncoder.java:179)
at org.eclipse.jetty.http2.generator.HeadersGenerator.generateHeaders(HeadersGenerator.java:72)
at org.eclipse.jetty.http2.generator.HeadersGenerator.generate(HeadersGenerator.java:56)
at org.eclipse.jetty.http2.generator.Generator.control(Generator.java:80)
at org.eclipse.jetty.http2.HTTP2Session$ControlEntry.generate(HTTP2Session.java:1143)
at org.eclipse.jetty.http2.HTTP2Flusher.process(HTTP2Flusher.java:168)
at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241)
at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224)
at org.eclipse.jetty.http2.HTTP2Session.frame(HTTP2Session.java:676)
at org.eclipse.jetty.http2.HTTP2Session.frames(HTTP2Session.java:648)
at org.eclipse.jetty.http2.HTTP2Stream.headers(HTTP2Stream.java:91)
at org.eclipse.jetty.http2.server.HttpTransportOverHTTP2.commit(HttpTransportOverHTTP2.java:185)
at org.eclipse.jetty.http2.server.HttpTransportOverHTTP2.send(HttpTransportOverHTTP2.java:111)
at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:687)
at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:743)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:234)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:218)
... 61 more
It seems (i have proven it), that PreEncodedHttpField cannot load all Implementations of HttpFieldPreEncoder over ServiceLoader.
Iterator<HttpFieldPreEncoder> iter = ServiceLoader.load(HttpFieldPreEncoder.class,PreEncodedHttpField.class.getClassLoader()).iterator();
ServiceLoader sees only a Http1FieldPreEncoder, which is in the same Bundle as PreEncodedHttpField, so observable for a BundleClassLoader. This Implementation is registerd under Index "0".
In my case, it should be used an HTTP/2 Implementation HpackFieldPreEncoder, which bundle in http2-hpack, but not visible for ServiceLoader
Is there any workaround to make this second implementation visible for PreEncodedHttpField to avoid my Exception?
Thank you
I am in process of upgrading a spring boot 1.3.3 project to 1.4.2.
After upgrading the project Spring boot will no longer use any application.properties file. It does not locate it. Even when passed as an startup argument.
The project is built with gradle and a shadowjar plugin to compile to a fat jar and start tomcat embedded from the jar.
The way the application is started is: java -jar app-all.jar. The directory containing the jar also contains the application.properties file. (and no other files)
There is no classpath set and the jar file does not contain any other application.properties files. (Tested with unzip -t app-all.jar |grep application.properties)
Starting the project under Spring Boot 1.3.3. The application starts correctly. Start of log file:
04:15:58.846 com.app.MaxApplication INFO [main] - Starting MaxApplication on test-ng with PID 30096 (/home/ubuntu/app-all.jar started by ubuntu in /home/ubuntu)
04:15:58.850 com.app.MaxApplication DEBUG [main] - Running with Spring Boot, Spring
04:15:58.850 com.app.MaxApplication INFO [main] - The following profiles are active: TEST
04:15:58.850 org.springframework.boot.SpringApplication DEBUG [main] - Loading source class com.app.MaxApplication
04:15:58.947 org.springframework.boot.context.config.ConfigFileApplicationListener DEBUG [main] - Activated profiles TEST
04:15:58.947 org.springframework.boot.context.config.ConfigFileApplicationListener DEBUG [main] - Loaded config file 'file:./application.properties'
Changing spring boot version to 1.4.2, cleaning gradle caches and rebuilding and running the application the same way Spring Boot does nto load the applciation.properties file and the application fails to start due to missing configuration settings provided by the file. Start of log file:
01:48:47.547 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [servletConfigInitParams] PropertySource with lowest search precedence
01:48:47.549 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [servletContextInitParams] PropertySource with lowest search precedence
01:48:47.551 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [systemProperties] PropertySource with lowest search precedence
01:48:47.552 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [systemEnvironment] PropertySource with lowest search precedence
01:48:47.552 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Initialized StandardServletEnvironment with PropertySources [servletConfigInitParams,servletContextInitParams,systemProperties,systemEnvironment]
01:48:47.552 [main] DEBUG org.springframework.core.env.PropertySourcesPropertyResolver - Could not find key 'spring.profiles.active' in any property source
01:48:47.552 [main] DEBUG org.springframework.core.env.PropertySourcesPropertyResolver - Could not find key 'spring.profiles.active' in any property source
01:48:47.554 [main] DEBUG org.springframework.core.env.PropertySourcesPropertyResolver - Could not find key 'banner.image.location' in any property source
01:48:47.555 [main] DEBUG org.springframework.core.env.PropertySourcesPropertyResolver - Could not find key 'banner.location' in any property source
01:48:47.556 [main] DEBUG org.springframework.core.env.PropertySourcesPropertyResolver - Could not find key 'banner.charset' in any property source
01:48:47.557 [main] DEBUG org.springframework.core.env.MutablePropertySources - Adding [version] PropertySource with lowest search precedence
01:48:47.560 [main] DEBUG org.springframework.core.env.MutablePropertySources - Adding [ansi] PropertySource with highest search precedence
01:48:47.561 [main] DEBUG org.springframework.core.env.MutablePropertySources - Adding [title] PropertySource with highest search precedence
01:48:47.600 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [servletConfigInitParams] PropertySource with lowest search precedence
01:48:47.600 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [servletContextInitParams] PropertySource with lowest search precedence
01:48:47.600 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [systemProperties] PropertySource with lowest search precedence
01:48:47.600 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Adding [systemEnvironment] PropertySource with lowest search precedence
01:48:47.601 [main] DEBUG org.springframework.web.context.support.StandardServletEnvironment - Initialized StandardServletEnvironment with PropertySources [servletConfigInitParams,servletContextInitParams,systemProperties,systemEnvironment]
01:48:47.637 [main] DEBUG org.springframework.context.annotation.ClassPathBeanDefinitionScanner - JSR-250 'javax.annotation.ManagedBean' found and supported for component scanning
01:48:47.649 [main] INFO com.app.MaxApplication - Starting MaxApplication on test-ng (/home/ubuntu/app-all.jar started by ubuntu in /home/ubuntu)
01:48:47.649 [main] DEBUG com.app.max.MaxApplication - Running with Spring Boot, Spring
01:48:47.650 [main] DEBUG org.springframework.core.env.PropertySourcesPropertyResolver - Could not find key 'spring.profiles.active' in any property source
01:48:47.650 [main] DEBUG org.springframework.core.env.PropertySourcesPropertyResolver - Could not find key 'spring.profiles.default' in any property source
01:48:47.650 [main] INFO com.app.max.MaxApplication - No active profile set, falling back to default profiles: default
01:48:47.650 [main] DEBUG org.springframework.boot.SpringApplication - Loading source class com.app.MaxApplication
Only two files in the current directory are the application.properties file and the jar file. The externalizing configration documentation says the configuration should be read from there. It also works under Spring 1.3.3
I have defined a configuration class (this is working in 1.3)
#Component
#Configuration
#SpringBootConfiguration
public class MaxApplicationProperties {
#Bean
public static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() {
return new PropertySourcesPlaceholderConfigurer();
}
}
I have tried:
Adding application.properties file to the class path.
Starting the application with --spring.config.location=application.properties (and with full path as well)
Setting config location environment variables.
Adding annotation #PropertySource("classpath:application.properties") to the MaxApplicationProperties class
Force deleting all downloaded libraries and having gradle re-download everything.
None of these options work to make Spring boot attempt to use the application.properties file the same was as Spring boot 1.3.
Anyone know what I am missing? Thanks.
I have a stored procedure in Sybase that returns some data in a temp table (let's call it #results). If I create this table from my own code and call the stored procedure and check the #results everything is fine (I use Python for this purpose). I can generate the expected result set for my test.
However when I try to create a DBUnit test case so that the code
creates the temp table via the Spring JdbcTemplate
calls this procedure and checks the returned data
I get a NoSuchTableException from DbUnit when checking the result set.
15:55:52.980 [main] DEBUG c.m.e.e.dbtest.helper.SQLTestHelper - *** expected table: #results
15:55:52.980 [main] DEBUG org.dbunit.dataset.FilteredDataSet - getTable(tableName=#results) - start
15:55:52.980 [main] DEBUG o.d.d.filter.SequenceTableFilter - accept(tableName=#results) - start
15:55:52.980 [main] DEBUG o.dbunit.dataset.OrderedTableNameMap - getTableName(tableName=#results) - start
15:55:52.980 [main] DEBUG o.dbunit.dataset.OrderedTableNameMap - getTableName(tableName=#results) - end - result=#RESULTS
15:55:52.980 [main] DEBUG org.dbunit.database.DatabaseDataSet - getTable(tableName=#results) - start
15:55:52.980 [main] DEBUG org.dbunit.database.DatabaseDataSet - initialize() - start
15:55:52.980 [main] DEBUG org.dbunit.database.DatabaseDataSet - Initializing the data set from the database...
15:55:52.980 [main] DEBUG o.d.d.DatabaseDataSourceConnection - getConnection() - start
15:55:52.980 [main] DEBUG m.b.t.TransactionResourceManager - Fetched TransactionResourceResolver [null]
15:55:52.980 [main] DEBUG msjava.pool.BasicObjectPool - Attempting to retrieve object from pool 'ConnectionPoolOf-dbunitDS'
15:55:52.980 [main] DEBUG msjava.pool.BasicObjectPool - Retrieved object 'TransactionInfoCachingConnection on DBCallSavingConnection on com.sybase.jdbc3.jdbc.SybConnection#170984c' from pool 'ConnectionPoolOf-dbunitDS'
15:55:53.402 [main] DEBUG org.dbunit.database.DatabaseDataSet -
database product name=Adaptive Server Enterprise
database major version=12
database minor version=5
jdbc driver name=jConnect (TM) for JDBC (TM)
jdbc driver version=jConnect (TM) for JDBC(TM)/6.05(Build 26564)/P/EBF16903/JDK14/Sun May 31 1:05:35 2009
jdbc driver major version=6
jdbc driver minor version=0
15:55:53.402 [main] DEBUG org.dbunit.database.DatabaseDataSet - metadata resultset=com.sybase.jdbc3.jdbc.SybResultSet#1b595f3
15:55:53.402 [main] DEBUG org.dbunit.database.DatabaseDataSet - getTableMetaData(tableName=#results) - start
15:55:53.402 [main] DEBUG org.dbunit.database.DatabaseDataSet - initialize() - start
15:55:53.402 [main] DEBUG o.dbunit.dataset.OrderedTableNameMap - getTableName(tableName=#results) - start
15:55:53.402 [main] DEBUG o.dbunit.dataset.OrderedTableNameMap - getTableName(tableName=#results) - end - result=#RESULTS
15:55:53.402 [main] ERROR org.dbunit.database.DatabaseDataSet - Table '#results' not found in tableMap=org.dbunit.dataset.OrderedTableNameMap[_tableNames=[], _tableMap={}, _caseSensitiveTableNames=false]
Checking the database in parallel with the test code execution (at a breakpoint) I can see that the temp table is indeed created in tempdb and filled with data.
Has anyone done such a thing successfully (eg. used a Sybase temp table from DbUnit)? If yes, how?
If you create temporary tables by using “#” as the first character of the table name:
Temporary tables:
Exist only for the duration of the user session or for the scope of the procedure that creates them
Cannot be shared between user connections
Are automatically dropped at the end of the session or procedure (or can be dropped manually)
You can create regular user tables in tempdb by specifying the database name in the command that creates the table:
Regular user tables in tempdb:
Can persist across sessions
Can be used by bulk copy operations
Can be shared by granting permissions on them
Must be explicitly dropped by the owner (otherwise, they are removed when Adaptive Server is restarted)
I'm using (the rather heavy weight) xtext to create a basic DSL parser and text highlighting.
I'm following the getting started tutorial at http://wiki.eclipse.org/Xtext/GettingStarted
The output in the console i'm getting is:
0 [main] INFO eclipse.emf.mwe.core.WorkflowRunner - --------------------------------------------------------------------------------------
0 [main] INFO eclipse.emf.mwe.core.WorkflowRunner - EMF Modeling Workflow Engine 0.7.2, Build v200908120417
0 [main] INFO eclipse.emf.mwe.core.WorkflowRunner - (c) 2005-2009 openarchitectureware.org and contributors
0 [main] INFO eclipse.emf.mwe.core.WorkflowRunner - --------------------------------------------------------------------------------------
0 [main] INFO eclipse.emf.mwe.core.WorkflowRunner - running workflow: C:/Users/Richard/workspace/org.xtext.example.mydsl.generator/src/workflow/MyDslGenerator.mwe
0 [main] INFO eclipse.emf.mwe.core.WorkflowRunner -
297 [main] ERROR eclipse.emf.mwe.core.WorkflowRunner - [ERROR]: Class not found: 'org.xtext.example.MyDslStandaloneSetup'(Element: bean register class='org.xtext.example.MyDslStandaloneSetup' in C:/Users/Richard/workspace/org.xtext.example.mydsl.generator/src/workflow/MyDslGenerator.mwe:11; Reported by: -UNKNOWN-)
297 [main] ERROR eclipse.emf.mwe.core.WorkflowRunner - Workflow interrupted because of configuration errors.
I get this output at step 4 "DSL Generation" in the tutorial.
The answer was a simple mestake made by me, while following the tutorial. In short I was running the incorrect .mwe file. The one I was running found in org.xtext.example.mydsl.generator/src/workflow while the .mwe I needed is listed under org.xtext.example.mydsl/src/org.xtext.example.