Using Squeryl inside a OSGi container - scala

Has anyone successfully gotten Squeryl to work inside a OSGi environment, specifically on Karaf 3.03.
So far I have gotten the individual dependencies to load, scala libraries, squeryl and the jdbc driver.The installed bundles look something like this:
51 | Resolved | 80 | 0.3.0.SNAPSHOT | ac.za.cput.pe.model
52 | Active | 80 | 2.11.6.v20150224-172222-092690e7bf | Scala Standard Library
53 | Active | 80 | 0 | wrap_mvn_org.squeryl_squeryl_2.10_0.9.5-6
54 | Active | 80 | 2.10.0.v20121205-112020-VFINAL-18481cef9b | Scala Standard Library
55 | Active | 80 | 0 | wrap_mvn_cglib_cglib-nodep_2.2
56 | Active | 80 | 0 | wrap_mvn_org.scala-lang_scalap_2.10.0
57 | Active | 80 | 2.10.0.v20121205-112020-VFINAL-18481cef9b | Scala Compiler
58 | Active | 80 | 2.10.0.v20121205-112020-VFINAL-18481cef9b | Scala Reflect
59 | Active | 80 | 0 | wrap_mvn_postgresql_postgresql_9.1-901-1.jdbc4
In my bundle I have code that looks like this:
Class.forName("org.postgresql.Driver")
SessionFactory.concreteFactory = Some(()=>
Session.create(
java.sql.DriverManager.getConnection("jdbc:postgresql://localhost:5432/pe","postgres"
,"12345"),new PostgreSqlAdapter
)
)
which basically tries to create squeryl session factory.
However when I start up karaf, this is the error I am getting:
java.lang.LinkageError: loader constraint violation: when resolving method "org.squeryl.SessionFactory$.concreteFactory_$eq(Lscala/Option;)V" the class loader (instance of org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of the current class, ac/za/cput/pe/model/activator/Activator, and the class loader (instance of org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) for resolved class, org/squeryl/SessionFactory$, have different Class objects for the type concreteFactory_$eq used in the signature
Does anyone have any ideas?, I am a few hours from jumping out of my balcony :(

Looks a lot like you got some different Jars included.
First make sure you have all dependencies correctly imported. Second make sure you don't embed those dependencies partially in your own bundles.
The Error message is very clear about the issue.
You compiled with a different version then the one that is provided to you during runtime. This Might be because of either a wrong import (make sure the version matches) or you include a different version of the package in your bundle.

Related

What do the various columns in schema_version_history table of flyway represent?

I'm new to flyway & have been going through the documentation of flyway but couldn't find a doc which describes what each column in schema_version_history (or whatever you would have configured to name the flyway table) means. I'm specifically intrigued by the column named "type". So far the possible values for this column that I've observed in some legacy project at work are SQL & DELETE.
But I have no clue what this means in terms of flyway migrations.
Below are some sample rows from the table. Note that for installed rank 54 & 56, same migration file is present with same checksum but one has type SQL and another has DELETE.
-[ RECORD 53 ]-+---------------------------------------------------------------------------------------------------
installed_rank | 54
version | 2022.11.18.11.35.49.65
description | add column seqence in attribute table
type | SQL
script | V2022_11_18_11_35_49_65__add_column_seqence_in_attribute_table.sql
checksum | 408921517
installed_by | postgres
installed_on | 2022-11-18 12:04:47.652058
execution_time | 345
success | t
-[ RECORD 54 ]-+---------------------------------------------------------------------------------------------------
installed_rank | 55
version | 2022.11.15.14.17.44.36
description | update address column in attribute table
type | DELETE
script | V2022_11_15_14_17_44_36__update_address_column_in_attribute_table.sql
checksum | 1347853326
installed_by | postgres
installed_on | 2022-11-18 14:52:09.265902
execution_time | 0
success | t
-[ RECORD 55 ]-+---------------------------------------------------------------------------------------------------
installed_rank | 56
version | 2022.11.18.11.35.49.65
description | add column seqence in attribute table
type | DELETE
script | V2022_11_18_11_35_49_65__add_column_seqence_in_attribute_table.sql
checksum | 408921517
installed_by | postgres
installed_on | 2022-11-18 14:52:09.265902
execution_time | 0
success | t
-[ RECORD 56 ]-+---------------------------------------------------------------------------------------------------
installed_rank | 58
version | 2022.11.18.11.35.49.65
description | add column seqence in attribute table
type | SQL
script | V2022_11_18_11_35_49_65__add_column_seqence_in_attribute_table.sql
checksum | 408921517
installed_by | postgres
installed_on | 2022-12-09 14:01:59.352589
execution_time | 174
success | t
Great question. This is as close as I got to documentation on that table:
https://www.red-gate.com/hub/product-learning/flyway/exploring-the-flyway-schema-history-table
That article doesn't really describe the type column well at all, suggesting it only has two possible values and I've seen at least three; DELETE, SQL and JDBC. Not sure what else it may have.
EDIT: Also now confirmed these two values; BASELINE and UNDO_SQL
It's actually marked as intentionally not documented since it's not a part of the public API:
https://flywaydb.org/documentation/learnmore/faq#case-sensitive

IntelliJ Scala: import works in test folder but not in main folder

I have an IntelliJ project in scala with the following directory structure (I've renamed files/directories for simplicity):
project
|
+--src
| |
| +--main
| | |
| | +--scala
| | |
| | +--'X'
| | |
| | +--'Y.scala'
| +--test
| |
| +--scala
| |
| +--'X'
| |
| +--'YSuite.scala'
|
+--build.sbt
The issue I'm having is that I'm able to import things in the YSuite.scala file that I'm not able to in YSuite.scala - specifically, the scala.collections.parallel packages. I just have no idea how or why I can import in the test file, but not in the parallel application file. I need them in the main file for implementation. Can someone point me in the right direction?
Screenshots are of the Y.scala file, YSuite.scala file, as well as the build.sbt file, if they help at all.
As can be seen, the red text indicates that I wasn't able to import it in Y.scala - when I hover over it with my mouse, it simply says cannot resolve symbol parallel. However, I've run the test file with some implementation of the parallel package, which runs with no problems.
Y.scala
YSuite.scala
build.sbt
a solution that seems to have worked for me:
step 1: File -> Invalidate Caches / Restart
step 2: build again/spin up sbt

Decision table x/y/z/foo.xls is in folder x/y/z but declares package 'Import'

I've got a simple decision table, like so:
+-----------+-----------------+--------+
|RuleSet |x.y.z | |
+-----------+-----------------+--------+
|Import |x.y.z.SomeClass | |
|RuleTable |theRules | |
|Name | Condition | Action |
|... | | |
+-----------+-----------------+--------+
When I import this into Business Central, I get this warning:
File 'x/y/z/foo.xls' is in folder 'x/y/z' but declares package 'Import'
If I build a kjar and use that in a Java program, I get the same warning.
Everything works fine, but I don't understand this warning. Is there something wrong in the layout of the decision table?

Service Loader config file doesn't explode properly

So I am writing a webapp in Eclipse and I want to use the serviceloader in one of my classes. Question is where to put the META-INF/services stuff. From here (https://stackoverflow.com/a/3421191/2742995) I found:
But the ideal way is to have it in your plugin's jar file. E.g if you
have a plugin bundled as WEB-INF/lib/myplugin.jar, and your plugin
class is com.example.plugin.MyPlugin Then the jar should have a
structure:
myplugin.jar!/META-INF/services/com.example.plugin.MyPlugin
So I have in the module containing the serviceloader stuff, the source: src/main/java/ containing
vcs.validation.* (containing the source code)
a folder: META-INF/services/vcs.validation.javatests.JavaTest containing:
Test1 (which reads vcs.validation.javatests.Test1) and
Test2 (which reads vcs.validation.javatests.Test2)
(The interface vcs.validation.javatests.JavaTest has two implementing classes Test1 and Test2)
However, when I package the whole webapp as a war and deploy in tomcat the web-app/WEB-INF/classes/ folder does not contain any META-INF/services/. What am I doing wrong here?
Structure should be:
Project
| Module
| | src
| | main
| | java
| | [ source code]
| | resources
| | META-INF
| | services
| | [service files]
instead of:
Project
| Module
| | src
| | main
| | java
| | [source code]
| | META-INF
| | services
| | [service files]
In this way the service files are no longer exploded to webapp/WEB-INF/classes/META-INF/services but just live in the jar in which they are packaged according to:
myplugin.jar!/META-INF/services/com.example.plugin.MyPlugin

Best Practices for Project Feature Sub-Modules with Mercurial and Eclipse?

I have a couple of ANT projects for several different clients; the directory structure I have for my projects looks like this:
L___standard_workspace
L___.hg
L___validation_commons-sub-proj <- JS Library/Module
| L___java
| | L___jar
| L___old_stuff
| L___src
| | L___css
| | L___js
| | L___validation_commons
| L___src-test
| L___js
L___v_file_attachment-sub-proj <- JS Library/Module
| L___java
| | L___jar
| L___src
| | L___css
| | L___js
| L___src-test
| L___js
L___z_business_logic-sub-proj <- JS Library/Module
| L___java
| | L___jar
| L___src
| L___css
| L___js
L____master-proj <- Master web-deployment module where js libraries are compiled to.
L___docs
L___java
| L___jar
| L___src
| L___AntTasks
| L___build
| | L___classes
| | L___com
| | L___company
| L___dist
| L___nbproject
| | L___private
| L___src
| L___com
| L___company
L___remoteConfig
L___src
| L___css
| | L___blueprint
| | | L___plugins
| | | | L___buttons
| | | | | L___icons
| | | | L___fancy-type
| | | | L___link-icons
| | | | | L___icons
| | | | L___rtl
| | | L___src
| | L___jsmvc
| L___img
| | L___background-shadows
| | L___banners
| | L___menu
| L___js
| | L___approve
| | L___cart
| | L___confirm
| | L___history
| | L___jsmvc
| | L___mixed
| | L___office
| L___stylesheets
| L___swf
L___src-standard
Within the working copy the modules compile the sub-project into a single Javascript file that is placed in the Javascript directory of the master project.
For example, the directories:
validation_commons-sub-proj
v_file_attachment-sub-proj
z_business_logic-sub-proj
...all are combined and minified (sort of like compiled) into a different Javascript filename in the _master-proj/js directory; and in the final step the _master-proj is compiled to be deployed to the server.
Now in regards to the way I'd like to set this up with hg, what I'd like to be able to do is clone the master project and its sub-projects from their own base-line repositories into a client's working-copy, so that modules can be added (using hg) to a particular customer's working copy.
Additionally however, when I do make some changes to/fix bugs in one customer's working copy, I would like to be able to optionally push the changes/bug fixes back to the master project/sub-project's base-line repository, for purposes of eventually pulling the changes/fixes into other customer's working copies that might contain the same bugs that need to be fixed.
In this way I will be able to utilize the same bug fixes across different clients.
However...I am uncertain of the best way to do this using hg and Eclipse.
I read here that you can use hg's Convert Extension to split a sub-directory into a separate project using the --filemap option.
However, I'm still a little bit confused as to if it would be better to use the Convert Extension or if it would be better to just house each of the modules in their own repository and check them out into a single workspace for each client.
Yep, it looks like subrepos are what you are looking for, but I think maybe that is the right answer for the wrong question and I strongly suspect that you'll run into similar issues that occur when using svn:externals
Instead I would recommend that you "publish" your combined and minified JS files to an artefact repository and use a dependency manager such as Ivy to pull specific versions of your artefacts into your master project. This approach give you far greater control over the sub-project versions your master project uses.
If you need to make bug fixes to a sub-project for a particular client, you can just make the fixes on the mainline for that sub-project, publish a new version (ideally via an automated build pipeline) and update their master project to use the new version. Oh, you wanted to test the new version with the their master project before publishing? In that case, before you push your fix, combine and minify your sub-project locally, publish it to a local repository and have the client's master project pick up that version for your testing.