As title, i want to konw how to dynamic modification KieBase in version 7.64.0.Final.
As i remanber i can use KnowledgeBase keep the rules in version 6.4。 but i dont know how to do this in version 7.64.0.
Here is my code in version 6.4
KnowledgeBuilder backageBuilder = KnowledgeBuilderFactory.newKnowledgeBuilder() ;
backageBuilder.add(ResourceFactory.newReaderResource(new StringReader(ruleFile)),
ResourceType.DRL );
backageBuilder.getKnowledgePackages()
Related
I am in the midst of upgrading the Spring version of one of our projects. As a result of this, the MongoDB library also had to be upgraded.
I am not able to track what the previous version of the MongoDB library used was, but the current version is now 3.9.1.
I have the following piece of code that doesn't work because of the upgrade, how should I rewrite it?
import com.mongodb.MongoClient;
import com.mongodb.MongoClientURI;
import com.mongodb.ServerAddress;
public sampleMethod() {
MongoClient client = null;
if (...) {
List<ServerAddress> saList = new ArrayList<>();
for (...) {
saList.add(...);
}
client = new MongoClient(saList);
} else if (...) {
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://...");
client = new MongoClient(mongoClientURI);
} else {
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://..." + this.encryptedProperties.getProperty("mongo.username") + "....");
client = new MongoClient(mongoClientURI);
}
return new MongoTemplate(client, srcDbname);
}
The problem now is with the return statement, because post Version 2.1, MongoTemplate's signature is now public MongoTemplate(com.mongodb.client.MongoClient mongoClient, String databaseName). Pre Version 2.1, it was public MongoTemplate(com.mongodb.MongoClient mongoClient, String databaseName).
I was looking at the documentation for the MongoClient interface (com.mongodb.client.MongoClient package) & it states that "Instances of this class can be created via the MongoClients factory.". Looking at MongoClients, the methods can't accommodate the creation of MongoClient with parameters List<ServerAddress>, MongoClientURI like MongoClient (com.mongodb.MongoClient package) does.
Package
Old Version
Link
New Version
Link
mongo-java-driver / com.mongodb
not sure, couldn't locate but will update
-
3.9.1
https://www.javadoc.io/static/org.mongodb/mongo-java-driver/3.9.1/index.html
org.springframework.data:spring-data-mongodb
2.0.8.RELEASE
https://docs.spring.io/spring-data/mongodb/docs/2.0.8.RELEASE/api/
3.2.0
https://docs.spring.io/spring-data/mongodb/docs/3.2.0/api/
Please bear with me as I am a junior dev (6 months of work experience) & I'm not familiar with upgrading project versions, thank you for your understanding
I am not sure how to proceed, I am currently reading the docs & doing some Google searches to see what a possible solution would be
I don't have experience in MongoDB
It looks like you're upgrading to version 3.2 of Spring Data MongoDB. As per the reference documentation, that major version series (3.x) requires you to use the 4.x version of the MongoDB Java Driver.
7.1. Dependency Changes Instead of the single artifact uber-jar mongo-java-driver, imports are now split to include separate
artifacts:
org.mongodb:mongodb-driver-core (required)
org.mongodb:mongodb-driver-sync (optional)
org.mongodb:mongodb-driver-reactivestreams (optional)
Depending on the application one of the mongodb-driver-sync,
mongodb-driver-reactivestreams artifacts is is required next to the
mandatory mongodb-driver-core. It is possible to combine the sync and
reactive drivers in one application if needed.
I have a ASP.NET WebForms application that uses some Ninject packages, but I am stuck at a certain version. When I try to upgrade to the latest version, I get "Unable to resolve dependencies" issues.
The packages in question are:
Package InstalledVer LatestVer
------------------------------------------------------
Ninject v3.2.2 v3.3.4
Ninject.Web v3.2.1 ✔ v3.2.1
Ninject.Web.Common v3.2.3 v3.3.1
Ninject.Web.Common.WebHost v3.2.3 v3.3.1
If I try updating Ninject, I get:
Unable to resolve dependencies. 'Ninject 3.3.4' is not compatible with
'Ninject.Web 3.2.1 constraint: Ninject (>= 3.2.0 && < 3.3.0)'
but Ninject.Web is already at the latest version!
Should I change the Dependency behaviour of Ninject.Web or would this be unsafe? If I do, what should I change the Dependency behavior to?
Thanks
Okay, so this is how to fix:
Remove the Ninject.Web package completely. This package is no longer required as it is now integrated into Ninject.Web.Common (well, version v3.3+ anyway)
Update the packages Ninject, Ninject.Web.Common and Ninject.Web.Common.WebHost. These should now upgrade okay. For me, they are both v3.3.1.
As part of the package upgrade a new file App_Start\Ninject.Web.Common.cs will have been added. This is just a rename of the existing App_Start\NinjectWeb.Common.cs so either [a] delete the new file or [b] migrate over your Ninject module registrations and remove the old file.
In web.config, you should now remove the OnePerRequestModule module:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="OnePerRequestModule" type="Ninject.Web.Common.OnePerRequestHttpModule" />
</modules>
</system.webServer>
This is because this module, is registered dynamically on loadup in the App_Start\Ninject.Web.Common.cs file's Start() method:
public static void Start()
{
DynamicModuleUtility.RegisterModule(typeof(OnePerRequestHttpModule));
DynamicModuleUtility.RegisterModule(typeof(NinjectHttpModule));
bootstrapper.Initialize(CreateKernel);
}
If you don't remove this entry from web.config then you can expect a type exception when launching your application, not least because as part of the version update, the class has moved from the Ninject.Web.Common namespace to Ninject.Web.Common.WebHost.
You can also remove the file App_Start\NinjectWeb.cs for the same reason (registering NinjectHttpModule)
If OnePerRequestHttpModule doesn't resolve in App_Start\Ninject.Web.Common.cs then add the following using statement to the file using Ninject.Web.Common.WebHost; (I think this is a missing reference in v3.3.1 of the package.
Hope this helps others.
I want to change EclipseLink from 2.5.0 to 2.5.1 in GlashFish 4.0. I have downloaded the OSGi bundle and replaced the following jar files
org.eclipse.persistence.antlr.jar
org.eclipse.persistence.jpa.jar
org.eclipse.persistence.asm.jar
org.eclipse.persistence.jpa.modelgen.jar
org.eclipse.persistence.core.jar
org.eclipse.persistence.oracle.jar
javax.persistence.jar
under $GLASSFISH_HOME/glassfish/modules.
After doing this, the version still remains the same. The following code,
String version = org.eclipse.persistence.Version.getVersion();
System.out.println("EclipseLink version : " + version);
still displays the version 2.5.0.
The bundle contains no eclipselink-x.x.x.jar.
What else is required to be changed? I'm using NetBeans 7.2.1.
You forgot some files, you need the complete list:
org.eclipse.persistence.antlr.jar
org.eclipse.persistence.asm.jar
org.eclipse.persistence.core.jar
org.eclipse.persistence.dbws.jar
org.eclipse.persistence.jpa.jpql.jar
org.eclipse.persistence.jpa.jar
org.eclipse.persistence.jpa.modelgen.jar
org.eclipse.persistence.moxy.jar
org.eclipse.persistence.oracle.jar
javax.persistence.jar
You don't have to rename the files, you can delete the old files starting with org.eclipse and copy the required files to the modules folder.
This should do the trick.
Update: If it doesn't work you may have to clear the OSGI cache. To do this shutdown the server and delete the folder felix in
$GLASSFISH_HOME/glassfish/domains/domain/osgi-cache/
Restart the server and wait a moment, it'll have to read the OSGI module information to rebuild the cache.
I've got an easy sample from the internet that works fine in the .NET 3.5 framework using System.ComponentModel.Composition.dll version v2.0.50727
I've changed the project definition and changed the target to .NET 4.0 and it works perfect.
When I replace the v2.0.50727 version of the above .dll to the latest version which is v4.0.30319 I get an error that complains during the composition of the container. The code where it break is as follows:
private void LoadPlugins() {
var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
var container = new CompositionContainer(catalog);
container.ExportsChanging += new EventHandler(container_ExportsChanging);
var batch = new CompositionBatch();
batch.AddPart(this);
container.Compose(batch); // throws Exception
}
And the exception is the following:
System.ComponentModel.Composition.ChangeRejectedException was unhandled
Message=The composition remains unchanged. The changes were rejected because of the following error(s): The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.
1) More than one export was found that matches the constraint '((exportDefinition.ContractName == "MefTutorial.IPlugin") AndAlso (exportDefinition.Metadata.ContainsKey("ExportTypeIdentity") AndAlso "MefTutorial.IPlugin".Equals(exportDefinition.Metadata.get_Item("ExportTypeIdentity"))))'.
Resulting in: Cannot set import 'MefTutorial.PluginConsumer._myPlugins (ContractName="MefTutorial.IPlugin")' on part 'MefTutorial.PluginConsumer'.
Element: MefTutorial.PluginConsumer._myPlugins (ContractName="MefTutorial.IPlugin") --> MefTutorial.PluginConsumer
What do I need to do to migrate to the .NET 4.0 concerning MEF?
Could it be that another project still references the .net 3.5 version? The error message says that there are two exports of type IPlugin, which I'm quite certain of means that finds both the 3.5 and 4.0 version of the dll.
Check that only the 4.0 version of MefTutorial is referenced and/or present.
OK, I found the problem. Apparently in the previous version the notation was as mentioned in my previous comment, but in the new .NET 4.0 version the syntax for import should be:
code>
[ImportMany(typeof(IPlugin))]
internal List _myPlugins { get; set; }
Notice the use of List and ImportMany instead of IList and Import.
How can I create a new build path entry for any *.jar file and add this classpath entry to the build path of an Eclipse project.
I have a plugin that should automatically setup my target project. So this project needs to have some library imports and I want to add this imports automatically using a wizard. The user just selects the location of a certain SDK and then some libraries have to be linked with the target project.
However, I found some references:
Importing libraries in Eclipse programmatically
How to add a folder to java build path as library, having multiple jars or entries in it?
Unfortunately, I failed to implement the second solution as I cannot find the classes IClasspathContainer, JavaCore and IJavaProject.
I'm using Eclipse Helios and JDK. Do I need any additional libraries to make changes to the build path or is there a simpler solution to import a jar library programmatically?
Regards,
Florian
I'm assuming that you are creating a plugin and need your plugin to manage the extra jars added to the classpath.
As you mention, you need to create a custom classpath container. First, create the classpath container extension by exending this extension point:
org.eclipse.jdt.core.classpathContainerInitializer
Then, you create a class that implements org.eclipse.jdt.core.IClasspathContainer and associate it with the extension point you just created.
You mention that you cannot find the org.eclipse.jdt.core.IClasspathContainer interface. You need to make sure that your plugin references the org.eclipse.jdt.core plugin in its MANIFEST.MF.
Here you can find some examples, how to define new classpath entries and classpath containers to java projects. I think it would handy for someone reading this question.
In order to get access to IJavaProject etc, goto your plugin.xml and add org.eclipse.jdt.core to the classpath. Thereafter you can import those packages into your project.
String projectName = "MyProject"; // project to add a library to
IProject project = ResourcesPlugin.getWorkspace().getRoot().getProject(projectName);
IJavaProject jProject = JavaCore.create(project);
for(File file : new File("path-to-some-directory-of-libraries-to-add").listFiles()){
if(file.isFile() && file.getName().endsWith(".jar")){
addProjectLibrary(jProject, file);
}
}
private static void addProjectLibrary(IJavaProject jProject, File jarLibrary) throws IOException, URISyntaxException, MalformedURLException, CoreException {
// copy the jar file into the project
InputStream jarLibraryInputStream = new BufferedInputStream(new FileInputStream(jarLibrary));
IFile libFile = jProject.getProject().getFile(jarLibrary.getName());
libFile.create(jarLibraryInputStream, false, null);
// create a classpath entry for the library
IClasspathEntry relativeLibraryEntry = new org.eclipse.jdt.internal.core.ClasspathEntry(
IPackageFragmentRoot.K_BINARY,
IClasspathEntry.CPE_LIBRARY, libFile.getLocation(),
ClasspathEntry.INCLUDE_ALL, // inclusion patterns
ClasspathEntry.EXCLUDE_NONE, // exclusion patterns
null, null, null, // specific output folder
false, // exported
ClasspathEntry.NO_ACCESS_RULES, false, // no access rules to combine
ClasspathEntry.NO_EXTRA_ATTRIBUTES);
// add the new classpath entry to the project's existing entries
IClasspathEntry[] oldEntries = jProject.getRawClasspath();
IClasspathEntry[] newEntries = new IClasspathEntry[oldEntries.length + 1];
System.arraycopy(oldEntries, 0, newEntries, 0, oldEntries.length);
newEntries[oldEntries.length] = relativeLibraryEntry;
jProject.setRawClasspath(newEntries, null);
}
Note that as Andrew Eisenberg mentioned, you need to include the org.eclipse.jdt.core plugin dependency in your plugin's MANIFEST.MF.
Note that you may also need to programmatically refresh the project too.