I have inherited model classes:
public class AbstractUser extends Model
and
public class User extends AbstractUser
I'm attempting to extend from a base project into several children project. The Users in each project will have many similar base attributes, but only one or two custom attributes. I'm hoping I can extend in such a way, so when bugs/updates come in regarding base classes, I only have to make updates to the base class. Alternatively, I'll have to have duplicated code across several projects. I'm planning on extending this to other classes as well. No prob doing this with the app.controllers.
My base class of course fires up just fine. In my extended classes, I'm executing:
mvn org.javalite:activejdbc-instrumentation:1.4.12:instrument
... then moving the exploded WAR into my Jetty webapp. Whenever I hit the extended model, I get the following stack trace:
org.javalite.activejdbc.InitException: failed to determine Model class name, are you sure models have been instrumented?
at org.javalite.activejdbc.Model.modelClass(Model.java:2726)
at org.javalite.activejdbc.Model.findAll(Model.java:2349)
at com.nearstar.model.ApplicationProperties.getInstance(ApplicationProperties.java:41)
at app.controllers.LoginController.login(LoginController.java:56)
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.javalite.activeweb.ControllerRunner.executeAction(ControllerRunner.java:289)
at org.javalite.activeweb.ControllerRunner.run(ControllerRunner.java:65)
at org.javalite.activeweb.RequestDispatcher.doFilter(RequestDispatcher.java:202)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:524)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:253)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
Is it possible to extend instrumented models in this manner?
First of all, if you get a message are you sure models have been instrumented?, it means that your models have not been instrumented. Maybe your IDE overwritten class files or script is not working, but this condition will cause this message.
Second, inheritance in ActiveJDBC does have some limitations. Please, take a look at this doc: http://javalite.io/inheritance.
What you want to do seems possible. I do not see much issue with that. However, in my projects I usually have a single common Maven module that contains all models, utility classes and services. I then use Maven dependency mechanism to pull common into other projects. This approach worked exceptionally well for many commercial projects for years.
Third, the package app.controllers is only necessary for ... controllers:) Your models can be placed into any package and module. As long as models are instrumented, and can be located on classspath, they will work as expected.
Related
When I use between dependencies together
<dependency>
<groupId>org.kie.server</groupId>
<artifactId>kie-server-client</artifactId>
</dependency>
<dependency>
<groupId>org.optaplanner</groupId>
<artifactId>optaplanner-spring-boot-starter</artifactId>
</dependency>
I get below warn
Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'solverManager' defined in class path resource [org/optaplanner/spring/boot/autoconfigure/OptaPlannerAutoConfiguration.class]: Unsatisfied dependency expressed through method 'solverManager' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'solverFactory' defined in class path resource [org/optaplanner/spring/boot/autoconfigure/OptaPlannerAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.optaplanner.core.api.solver.SolverFactory]: Factory method 'solverFactory' threw exception; nested exception is java.lang.NoClassDefFoundError: org/drools/core/reteoo/CoreComponentFactory
and then an exception.
Do you know how I can use these two dependencies together?
I'm adding a second answer which takes an entirely different approach.
The Spring Boot starter is a way to develop standalone OptaPlanner-based applications. KIE Server is an application that embeds OptaPlanner and allows third parties to run solvers on KIE Server.
From this point of view, the two are fundamentally incompatible:
Are you embedding OptaPlanner? Use the Spring Boot starter.
Are you talking to KIE Server? Use the client.
I fail to see how you would even combine both in a single JAR.
The fact still stands, though - KIE Server is an obsolete technology, and OptaPlanner 8 does not support it.
OptaPlanner 8 and Drools 7 can not be used together. OptaPlanner 8 relies on Drools 8, and that will cause all sorts of classpath conflicts.
There is a way how to use OptaPlanner 8 without Drools. Assuming you do not use score DRL (or, if you're using constraint streams, you switch to the BAVET implementation) you will be able to remove all Drools dependencies from OptaPlanner 8. However, I can not guarantee that this will not blow up for some other reason, as it's never been tried; the safest answer is that this is just not going to work. OptaPlanner 8 requires Drools 8.
Another option is to use OptaPlanner 7 which has been designed to work with KIE, but that (very old) version is no longer maintained by the community.
I am injecting a model from outside into MPS.
For this purpose, I followed the steps:
create a language that reflects the model I want to inject
create an Intention that gathers the paths to the source models
parse those model files and instantiate the AST in MPS
Testing at different levels requires that I pass wrong paths and create files, to throw and capture exceptions. How can I test such in MPS?
Could we use TempDirTestFixture in test cases inside MPS?
Is there in MPS something like JUnit's TempDirectory?
I tried to use TempDirTestFixtureImpl by adding MPS.IDEA and com.intellij.testFramework.fixtures to my test module, but MPS still complains with the following error:
java.lang.NoClassDefFoundError: com/intellij/concurrency/IdeaForkJoinWorkerThreadFactory
1 ERROR JUnitTestExecutor - Exception in the test framework
at com.intellij.testFramework.fixtures.impl.BaseFixture.<clinit>(BaseFixture.java:22)
java.lang.NoClassDefFoundError: com/intellij/concurrency/IdeaForkJoinWorkerThreadFactory
at java.base/java.lang.Class.forName0(Native Method)
at com.intellij.testFramework.fixtures.impl.BaseFixture.<clinit>(BaseFixture.java:22)
I want to use musicg to analysis audio fingerprint.
But I got following error in musicg library.
IllegalAccessError: class Test
(in unnamed module #0x33f88ab) cannot access class com.sun.media.sound.FFT
(in module java.desktop)
because module java.desktop does not export com.sun.media.sound to unnamed module #0x33f88ab
What should I do?
Environment
Kotlin
JDK 17(downgrade available)
musicg 1.4.2.2
My code
fun main(args: Array<String>) {
FFT(10, 20)
}
got exception in FFT(10, 20)
com.sun and its sub-packages are not part of the public Java API. They implement some standard Java APIs, but you shouldn't refer to them directly. (They're likely to change and/or be renamed or removed between JVM releases, and non-Sun/Oracle JVMs probably won't have them at all.)
In most cases you should access the public API classes (e.g. in javax.sound) instead. (Those may use sun.*/com.sun.*/etc. classes internally as needed, but that's merely an implementation detail.)
In early versions of Java, there was nothing to stop people using those internal implementation classes, and so some developers got into bad habits. But Java 9 added a module system, which restricts access to them. The error message you see is a result of that.
The details are in JEP 260. The intent was that there would be public APIs for all of the critical APIs that were being restricted. However, according to this Oracle forum page, the work wasn't completed, and so there are some internal APIs for which no public equivalent exists yet.
FFT looks like one of those classes that has been overlooked. I can't see a direct replacement for it, I'm afraid. Is there a third-party library you can use? This question gives some options.
Still trying to run Optaplanner on our projects, today I tried to separate in multi modules our applications but got some troubles with Optaplanner.
So we have multiple gradles modules that looks like this:
app -> Contains the #SpringBootApplication
referentialdata -> Contains almost all our entities / repository / etc
auth -> Contains the authentication logic
simulation -> Contains the solver logic
And they are all under the parent build.gradle file
It seems that if I move my ConstraintProvider from the base module (app) where the SpringBootApplication is to another module (simulation), then I go this error.. All the other solver related things (like the SolverConfig.xml, the SolverService where I invoke the solver are already in the simulation module), the SpringBootApplication is well scanning the packages containing the ConstraintProvider as the entities and repositories under the same package are detected
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.optaplanner.core.config.solver.SolverConfig]: Factory method 'solverConfig' threw exception; nested exception is java.lang.IllegalStateException: No classes found that implement EasyScoreCalculator, ConstraintProvider or IncrementalScoreCalculator.
Neither was a property optaplanner.score-drl defined, nor a constraints.drl resource found.
Maybe your ConstraintProvider class is not in a subpackage of your #SpringBootApplication annotated class's package.
Maybe move your constraint provider class to your application class's (sub)package.
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) ~[spring-beans-5.3.1.jar:5.3.1]
at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:651) ~[spring-beans-5.3.1.jar:5.3.1]
... 48 common frames omitted
Here is my configuration (the paths are good):
<?xml version="1.0" encoding="UTF-8"?>
<solver>
<solutionClass>com.api.simulation.impl.domain.optimizer.AllocationProblemSolution</solutionClass>
<entityClass>com.api.simulation.impl.domain.optimizer.OptimizerAffectation</entityClass>
<termination>
<secondsSpentLimit>160</secondsSpentLimit>
</termination>
<scoreDirectorFactory>
<!-- <scoreDrl>com.api.simulation.optim/rules.drl</scoreDrl>-->
<constraintProviderClass>com.api.simulation.impl.AllocationConstraintProvider</constraintProviderClass>
</scoreDirectorFactory>
</solver>
Is there a way to make it work in submodules or should the constraint provider be in the main module ?
The error message says that this is intentional, and it also hints at what you need to do to fix that:
Maybe your ConstraintProvider class is not in a subpackage of your #SpringBootApplication annotated class's package.
It's been a while since that code was written, and we are currently evaluating whether or not we still need to place that limitation on users. I will update my answer here if/when we decide to change the behavior.
I am currently experiencing a problem in my RCP application and wanted to ask, if someone stumbled over the same problem and can give me some valuable hints:
My RCP application allows plugins to provide implementations of a specific abstract class of my model (singleton) to extend my model during runtime via the update manager. I instantiate these classes via
extensionPointImplementation.createExecutableExtension(..)
after parsing the Eclipse registry. I can serialize the created instances using the default Java serialization API.
Now to the problem: The plugin trying to deserialize the objects cannot find the class implementations of the model extensions due to the fact, that there is no plugin dependency between the plugins. Nevertheless, it is not possible for me to create such a dependency which would make the idea of extending the model during runtime obsolete.
Is it possible to solve this problem by using the default Java serialization API or do I have to implement my own serialization (which parses the Eclipse registry and creates the instances via the line shown above if all necessary plugins are available, otherwise throw an exception) which might be based on the default Java serialization API (if possible I do not want to create the serialization completely by myself)?
Thanks.
You need to define a so called buddy policy.
In the bundle trying to instantiate the class add
Eclipse-BuddyPolicy: registered
to the manifest.mf.
In the bundle providing the class add
Eclipse-RegisterBuddy: <symbolic name of the bundle instantiating the class>
to the manifest.mf.