I am working ON Puppets Learning VM which uses Ruby which I am not too familiar with. I am stuck on Exercise 5. Manifests and classes, Task 2 https://kjhenner.gitbooks.io/puppet-quest-guide/content/quests/manifests_and_classes.html
In the previous Task I create cowsay.pp :
class cowsayings::cowsay {
package { 'cowsay':
ensure => present,
provider => 'gem',
}
}
Then in task two I am suppose to create the same file in another location with instructions:
Task 2:
If you were going to apply this code to your production infrastructure, you would use the console's node classifier to classify any nodes that needed cowsay installed with the cowsay with your cowsay class. As you're working on a module, however, it's useful to apply a class directly. By convention, these test manifests are kept in an examples directory. (You may also sometimes see these manifests in the tests directory.)
To actually declare the class, create a cowsay.pp test in the examples directory.
vim cowsayings/examples/cowsay.pp
In this manifest, declare the cowsay class with the include keyword.
include cowsayings::cowsay
I am not sure how to create this second file and where to add this line. I have tried both:
class cowsayings::coway {
include cowsayings::cowsay
package { 'cowsay':
ensure => present,
provider => 'gem',
}
}
and
class cowsayings{
include cowsayings::cowsay
}
Although it does not seem to be working and when I run it, it does not install cowsay correctly in Task 3 (in the link above that I posted
The manifest in the examples directory just needs that one line with "include cowsayings::cowsay".
There are two tasks that have to happen with puppet, "defining" classes and "declaring" them. The cowsayings/manifests/cowsay.pp contains the definition, but you need to actually declare the class in order to make something happen.
That's what puppet apply cowsayings/examples/cowsay.pp does, it declares the class.
Related
I'm trying to run a full ADTF configuration from my own C++ command-line application using the ADTF SDK. ADTF version: 2.9.1 (pretty old).
Here's what I have (want) to do:
Load manifest file
Load globals-xml
Load config-xml
2 & 3 are done, using the session-manager service - see ISessionManager interface: https://support.digitalwerk.net/adtf/v2/adtf_sdk_html_docs/classadtf_1_1_i_session_manager.html , functions LoadGlobalsFromFile & LoadConfigFromFile.
The problem is that I don't know how to do point 1: currently, instead of loading a manifest, I manually load the list of services myself using _runtime->RegisterPlugin, _runtime->CreateInstance and _runtime->RegisterObject.
What I've managed to do is to load only the namespace service and use the INamespace interface which has a method for loading manifest files: https://support.digitalwerk.net/adtf/v2/adtf_sdk_html_docs/classadtf_1_1_i_namespace.html - see ImportFile with ui32ImportFlags = CF_IMPORT_MANIFEST.
But this only loads the manifest settings into the namespace, it doesn't actually instantiate the services. I could do it manually, by:
Do _runtime->RegisterPlugin for every url under
root/plugins/ in the namespace
Do _runtime->CreateInstance for every objectid under
root/services/ in the namespace
But I want this to be more robust and I'm hoping there's already a service that handles the populated namespace subsequently and does these actions. Is there such a service?
Note: if you know how this could be done in ADTF3 that might also be of help for me, so don't hesitate to answer/comment
UPDATE
See "Flow of the system" on this page: https://support.digitalwerk.net/adtf/v2/adtf_sdk_html_docs/page_service_layer.html
Apparently the runtime instance itself handles the manifest file (see run-levels shutdown & kernel) but I don't know how I'm supposed to tell it where it is.
I've tried setting the command-line arguments to be count = 2 and the 2nd = manifest file path when instantiating cRuntime. It doesn't work :).
In ADTF3 you can just use the supplied cADTFSystem class to initiate an ADTF system and then use the ISessionManager interface to load a session of your choice.
Found the answer, not exactly what I expected though. I tried debugging adtf_runtime.exe to find out what arguments it passes to cRuntime.
The result is indeed similar to what I've suspected (and actually tried):
arg1 = adtf_runtime.exe (argv[0] in adtf_runtime)
arg2 = full path to manifest file (e.g. $(ADTF_DIR)\bin\adtf_devenv.manifest)
arg3 = basename of manifest file, without extension (e.g. "adtf_devenv")
While this suggested that cRuntime indeed is responsible with loading and handling the manifest, it turned out to be NOT quite so, passing the same arguments to it did not do the job. The answer came when I noticed that adtf_runtime.exe was actually using an extension of cRuntime called cRuntimeEx which is NOT part of the SDK (at least I haven't found it).
This class IS among the exported symbols of the ADTF SDK library, i.e. a "dumpbin /symbols adtfsdk_290.lib" renders at some point:
public: __cdecl adtf::cRuntimeEx::cRuntimeEx(int,char const * *
const,class ucom::IException * *)
but it is NOT part of the SDK (you won't find a header file defining it).
Among its methods you'll also find this:
protected: long __cdecl adtf::cRuntimeEx::LoadManifest(class adtf_util::cString const &,class std::set,class std::allocator > *,class ucom::IException * *)
Voila. And thus, unfortunately, I cannot achieve what I wanted in a robust fashion. :)
I ended up manually implementing the manifest-loading logic, since cRuntimeEx is not made available within the SDK. Something along these lines:
Use a cDOM instance to load the manifest file
Call FindNodes("/adtf:manifest/environment/variable") to find the environment-variables that need to be set and set them using "cSystem::SetEnvVariable"
Call FindNodes("/adtf:manifest/dependencies/platform") to find library dependencies and use cDynamicLinkage::Load to load the libraries that target the current platform (win32/linux)
Call FindNodes("/adtf:manifest/plugins/plugin") to find the services to be loaded using _runtime->RegisterPlugin (you may also handle "optional" attribute)
Call FindNodes("/adtf:manifest/services/service") to find the services that need to be created using _runtime->CreateInstance and _runtime->RegisterObject (you may also handle "optional" attribute)
And, finally, call FindNodes("/adtf:manifest/manifests/manifest") to (recursively) load child-manifests (you may also handle "optional" attribute)
The only thing you need to do is start the adtf launcher with the meta files (manifest. This works for adtf 2 as well as for adtf 3. It can be done (console) application. If you also want to do a little bit more in adtf 3, you can use adtf control instead of adtf launcher with its scripting interface (see the scripts under examples)
How do I configure my created services to be able to be type-hinted? I have looked in all the service container docs, and anything to do with symfony docs and nothing I am trying works...
Added this to services.yml
Tester:
class: AppBundle\Services\Tester
public: true
Added this to my class
use AppBundle\Services\Tester;
Tried to type-hint "Tester $test" and get errors. Doing something wrong...
In this instance, Tester is a service name, as opposed to a classname that is a service.
If you have a the class in that location, and you also want it to be public (to use in a $container->get('\AppBundle\Services\Tester') or ->get(Tester::class), you can define it like this.
AppBundle\Services\Tester:
public: true
If you are only going to be using it as a type-hint, you don't need the public:true, and if the class is being imported elsewhere (probably further up the same file), you may not even need the lines at all unless it has parameters that can't themselves be autowired.
If you only need it to be get()-able in a test environment, it can be worth just creating a service alias, only for services_tesy.yml:
# available as ->get('test_Tester') in a test
test_Tester:
class: AppBundle\Services\Tester:
public: true
I found what I needed. I was having problems with the yaml editor in Eclipse. It was making a mess of tabs and was continually giving me problems in other areas too. I ended up installing YEdit and everything seemed to work.
I am trying to write nice unit tests for my already created REST API. I have this simple structure:
ROOT/
config/
handlers/
lib/
models/
router/
main.go
config contains configuration in JSON and one simple config.go that reads and parses JSON file and fills the Config struct. handlers contains controllers (i.e. handlers of respective METHOD+URL described in router/routes.go). lib contains some DB, request responder and logger logic. models contains structs and their funcs to be mapped from-to JSON and DB. Finally router contains the router and routes definition.
Now I was searching and reading a lot about unit testing REST APIs in GO and found more or less satisfying articles about how to set up a testing server, define routes and test my requests. All fine. BUT only if you want to test a single file!
My problem is now how to set up the testing environment (server, routes, DB connection) for all handlers? With the approach found here (which I find very easy to understand and implement) I have one problem: either I have to run tests separately for each handler or I have to write test suites for all handlers in just one test file. I believe you understand that both cases are not very happy (1st because I need to preserve that running go test runs all tests that succeed and 2nd because having one test file to cover all handler funcs would become unmaintainable).
By now I have succeeded (according to the linked article) only if I put all testing and initializing code into just one func per XYZhandler_test.go file but I don't like this approach as well.
What I would like to achieve is kind of setUp() or init() that runs once with first triggered test making all required variables globally visible and initialized so that all next tests could use them already without the need of instantiating them again while making sure that this setup file is compiled only for tests...
I am not sure if this is completely clear or if some code example is required for this kind of question (other than what is already linked in the article but I will add anything that you think is required, just tell me!
Test packages, not files!
Since you're testing handlers/endpoints it would make sense to put all your _test files in either the handlers or the router package. (e.g. one file per endpoint/handler).
Also, don't use init() to setup your tests. The testing package specifies a function with the following signature:
func TestMain(m *testing.M)
The generated test will call TestMain(m) instead of running the tests
directly. TestMain runs in the main goroutine and can do whatever
setup and teardown is necessary around a call to m.Run. It should then
call os.Exit with the result of m.Run
Inside the TestMain function you can do whatever setup you need in order to run your tests. If you have global variables, this is the place to declare and initialize them. You only need to do this once per package, so it makes sense to put the TestMain code in a seperate _test file. For example:
package router
import (
"testing"
"net/http/httptest"
)
var (
testServer *httptest.Server
)
func TestMain(m *testing.M) {
// setup the test server
router := ConfigureRouter()
testServer = httptest.NewServer(router)
// run tests
os.Exit(m.Run())
}
Finally run the tests with go test my/package/router.
Perhaps you could put the setup code that you want to use from multiple unit test files into a separate package that only the unit tests use?
Or you could put the setup code into the normal package and just use it from the unit tests.
It's been asked before but the Go authors have chosen not to implicitly supply a test tag that could be used to selectively enable function compiles within the normal package files.
If I download a chat software on word press, it is called a Plugin. In Zend Framework it's called a Module, but there is also plugin's for Controllers.
What's the difference between modules and plugins in Zend?
A module in zf2 is similar to a plugin in wordpress yes! They are a collection of different classes that can be loaded into a project and allow either for reuse of generic code in other projects (this would be using composer in zf2) or modules can simply be used as groupings for similar code in a project.
zf2 is itself modular (I could just load some of the modules in my project, they are designed to work standalone) but lets not do that here
composer.json
{
"name": "myApp",
"require": {
"php": ">=5.3.3",
"zendframework/zendframework": "~2.3.0",
"zf-commons/zfc-twig": "dev-1.2rc1"
},
"autoload": {
"psr-0": {
"Application": "module/Application/src/"
}
}
}
providing composer is installed I can just run:
composer update
from the command line. If you haven't had much experience with composer, the docs ain't bad https://getcomposer.org/doc/ but it is a must have for zf2 development!
Then in the root of your app you can then add to config.application.config.php your modules
return array(
'modules' => array(
'zfTwig',
'MyCustomModule',
),
}
Now these modules are available in your project. For more information see
http://www.michaelgallego.fr/blog/2013/01/21/some-tips-to-write-better-zend-framework-2-modules/
and
http://mwop.net/blog/267-Getting-started-writing-ZF2-modules.html
You can also add modules yourself at the application level (as I said previously these are more for grouping features or whatever you fancy together).
You can use this to help build your personal modules
https://github.com/zendframework/ZendSkeletonModule
Just place the ZendSkeletonModule in the module folder of your zf2 app and update all the namespaces and the root folder of the module to match. In the case of the application.config.php I have above you would rename it all "MyCustomModule".
A controller plugin is something quite different, they are just a class which is registered to be injected into a controller basically
They can be called in your controllers to perform certain tasks.
The FlashMessenger plugin for example allows you to register a message in the flash messenger within your controller that will be displayed on the next page load.
From the zf2 docs
$this->flashMessenger()->addMessage('You are now logged in.');
return $this->redirect()->toRoute('user-success');
see http://framework.zend.com/manual/2.0/en/modules/zend.mvc.plugins.html for more detail
Modules
A module is a self contained collection of code that provides similar functionality within an application.
This means modules can be anything you desire them to be (one file or your whole application!).
'Modules' are not new terminology in ZF2; "Modular Programming" has been around for a long time. By having logical groups of code functionality it will promote code reuse and the 'open close principle'.
Modules in ZF2
Modules are first class citizens within Zend Framework 2; this means that the framework was designed specifically for the purpose of being able to add and remove modules with ease.
There are many examples of ZF2 modules online - Most of which would require minor configuration changes and you can begin using them (code reuse!)
Plugins
Again a generic term that will have different meanings in different frameworks. You may have heard of 'pluggable software', this answer summaries it nicely.
[A design for when] you want a system to work in straightforward and predictable ways, with very specific points of variation.
The 'points of variation' are areas of your code that are likely to require changes or different logic. A system that allows for external sources to be injected without the base code being modified is thought to be 'plugable'.
Plugins in ZF2
A 'Plugin' in ZF2 is actually known as a 'Controller plugin'
They are classes designed to add functionality to Controllers (any class extending Zend\Mvc\Controller\AbstractActionController), without the need to extend the controller class.
Some examples of this are the Zend\Mvc\Controller\Plugin\FlashMessenger which allows you to add a message to session and display it on the reloaded page. This can be reused in all your controllers without needing to modify them.
I work on a complex, multi-module maven project. One of the modules is an executable jar that implements a command-line application. I need to integration test this application. I need to run it several times, with several different command-lines and validate the exit status and stdout/err. However, I can't find a plugin for maven that claims to support this, and also can't track down a JUnit library that supports testing command-line applications.
Before you say 'don't test the main method - instead do bla', in this case I really do mean to test the main method, not some subsidiary functionality. The whole point is to run the application as a user would in its own VM and environment, and validate that it is behaving itself - parsing command-line options correctly, exiting with the write status and hot-loading the right classes from the right plugin jars.
My current hack is to use apache-exec from within a junit test method. It appears to be working, but is quite fiddly to set up.
public void testCommandlineApp()
throws IOException
{
CommandLine cl = new CommandLine(resolveScriptNameForOS("./runme")); // add .sh/.bat
cl.addArgument("inputFile.xml");
exec.setWorkingDirectory(workingDir);
exec.setExitValues(new int[] { 0, 1, 2 });
int exitCode = exec.execute(cl);
assertEquals("Exit code should be zero", 0, exitCode);
}
Why not simply use a shell script, using the maven-exec-plugin to build your classpath?
STDOUT=$(mvn exec:java -DmainClass=yourMainClass --arg1 --arg2=value2)
RETURN_CODE=$?
# validate STDOUT
# validate RETURN_CODE
You can even use something like shunit2 if you prefer a more structured approach.