How can I make OrionLD recognize when I update the content of a context file referenced by OrionLD?
In previous versions of OrionLD, you could get the latest context by restarting OrionLD.
However, with the implementation of the Persist context cache feature, it is no longer possible to overwrite the context information.
(https://github.com/FIWARE/context.Orion-LD/pull/844)
Is there any way to do this?
I restarted OrionLD and mongoDB, but
OrionLD and mongoDB were restarted, but the latest context was not recognized.
Do I need to manually delete the document in mongoDB where the context information is stored?
■My environment
・Orion
：fiware/orion-ld:latest
(post-v0.8.1)
・Mongo
：mongo:3.6
Thank you.
Sorry about that. We recently defined how this is to work in ETSI ISG CIM, the workgroup that defines the NGSI-LD API. It's not public yet, but I will try to implement this asap anyway. As of right now, yeah, I'm afraid a manual delete from mongo is the only way to do it.
WAIT ...
I did implement the DELETE request on cached contexts. For that you'll need the local identifier (GET /ngsi-ld/v1/jsonldContexts). Once you have the local identifier you can ask the broker to DELETE the context and after that, it will be downloaded anew.
It's a pretty good "workaround" until I implement the "overwrite" option for cached contexts.
Related
JGit used to rely on JSch as its transport provider, but changed because JSch does not accept certain keys, including some OpenSSH ones.
If you are using a passphrase-encrypted key with JGit, the recommended approach with JSch used to be to override a configuration callback, as shown in this blog article.
The alternative is to set a shared session factory and this also what the Apache MINA team recommends with a pointer to the cost of creating sessions on demand.
However, my issue with this is that it sets a specific provider for the whole system scope. Consequently, I would like to implement TransportConfigCallback. Ultimately, this requires to adapt SshSessionFactory to MINA's session initialization code and produce a RemoteSession.
Has anyone done this or seen any boilerplate code?
Self answer after some research: The interface to MINA in JGit is deliberately set closed. The driver only accepts a regular Git configuration directory. And this is the key to configuring the system:
Provide a different git configuration directory for each user.
Provide regular git configuration (git config) files underneath for all special settings
JGit has classes to write Git configurations, so you do not need to write any parsing and serialisation code.
I will update this answer with pertinent links to the classes and source code locations involved.
From version 5.5 the factory can be configured for this usecase. See NoFilesSshTest.java for details on how to use a database to provide connection information.
I currently use RoleEnvironment.GetConfigurationSettingValue(propertyName) to get the value of a setting defined in my WebRole config file (csdef + cscfg). Ok, sounds right.
This works well if the setting exists but failed with an Exception if the setting is not defined in the csdef and the cscfg.
I'm migrating an existing app to Azure which has many configuration settings in web.config. In my code, to read a setting value, I d'like to test : if it exists in the webRole config (csdef + cscfg) I read it from here, otherwise I read it with ConfigurationManager from web.config.
This would prevent to migrate all settings from my web.config and allow to custom one when the app is already deployed.
Is there a way to do this ?
I don't want to encapsulate the GetConfigurationSettingValue in a try/catch (and read from web.config if I enter the catch) because it's really an ugly way (and mostly it's not performance effective !).
Thanks !
Update for 1.7 Azure SDK.
The CloudConfigurationManager class has been introduced. The allows for a single GetSetting call to look in your cscfg first and then fall back to web.config if the key is not found.
http://msdn.microsoft.com/en-us/LIBRARY/jj157248
Pre 1.7 SDK
Simple answer is no. (That I know of)
The more interesting topic is to consider configuration as a dependency. I have found it to be beneficial to treat configuration settings as a dependency so that the backing implementation can be changed over time. That implementation may be a fake for testing or something more complex like switching from .config/.cscfg to a database implementation for multi-tennent solutions.
Given this configuration wrapper you can write that TryGetSetting as internal method for whatever your source of configuration options are. When this feature is added to the RoleEnvironment members, you would only have to change that internal implementation.
I am working on a project with developers around the globe and we are using mercurial for our source control solution. Currently, we communicate our change sets by creating bundles and posting to a mailing list. A disagreement has arisen about best practices, and we have not been able to find an answer in the mercurial documentation.
When creating a bundle, is there any sort of internal integrity check that occurs? Or should we be sending digests along with the change set to ensure file integrity?
A bundle contains exactly the same data as the data transferred by the wire protocol. Due to the way mercurial works, there's a recursive hashing scheme going on, so every revision must be uncorrupted in order to be used.
I'm trying to implement the advice found in this great blog post for batch processing in grails with MySQL. The problem that I'm having is that inclusion of periodic calls to session.clear() in my loop causes org.hibernate.LazyInitializationException's to be thrown. There's a quote down in the comments section of the page:
You’re second point about potentially
causing LIEs is absolutely true. If
you’re doing other things outside of
importing with the current thread,
you’ll want to make sure to reattach
any objects to the session after
you’re doing your clearing.
But how do I do that? Can anyone help me specifically understand how to "reattach any objects to the session after I'm done clearing?
I'm also interested in parallelizing the database insertion process so that I can take advantage of having a multi core processor. Can anyone provide advice on how to do that in Grails?
Grails has a few methods to help with this (they leverage hibernate under the covers).
If you know an object is detached, you can use the attach method to reconnect it.
If you've made changes to the object while it was detatched, you can use merge.
If for whatever reason, you're not sure if an object is attached to the session, you can use the link text method to find out if it is or isn't.
It might also be worth reviewing the Hibernate documentation on Session.
I've recently started to play with Ruby on Rails which favours convention over configuration and relies on sensible defaults to tie various aspects of the application together.
I was thinking that it might be useful if this concept of sensible default configuration was used in general configation for various frameworks then it might save some development headache.
For example, in a .net app I usually want to log an exception in the windows event log using enterprise library exception handling block but if I don't explicity state the behaviour I want in a config file then EL will complain. I think that instead, if it can't find custom configuration then it should revert to a sensible default configuration, like logging my exception in the event log.
Would this be a good or bad concept for frameworks to adopt for their configuration?
I work a lot with a framework that does this exact thing. My trouble with this way of working is that:
the framework grew to having an excessive amount of configuration keys that are actually never used/set in a configuration file.
behavior of the software becomes implicit sometimes, I want to explicitly set the system to behave a certain way instead of having it fallback on some other code path due to a 'default'.
a missed typo in configuration key may result in a very long diagnostic session before figuring out what is going on.
When forgetting to set a configuration value I rather have the software tell me, instead of assuming some form of behavior that I might not at all be after.
I'd prefer a 'template' configuration file in which I change what I want and have the unchanged settings serve as the default.
Figuring which out which convention the software picked when debugging can be a lot of time wasted also.