Is there any way to configure log4php to output logs only for a given class?
yes, there are two ways.
One is already supported by Log4php. You can configure to only log a specific logger:
log4php.logger.com.foo.Myclass=WARN
The other one is more complicated. You can create your own Filter:
http://logging.apache.org/log4php/docs/appender-filter.html
A filter is a class which extends Log4PHP LoggerFilter interface. An example how a filter is implemented can be found here:
http://svn.apache.org/viewvc/logging/log4php/trunk/src/main/php/filters/LoggerFilterStringMatch.php?view=markup
Cheers,
Christian
Related
I want to create dynamic group in openldap with Apache Directory Studio but groupOfURLs object class not available.
The dynamic group feature is not present by default (that's why you can't find the groupOfURLs object class). You need to define and add the dyngroup.schema to cn=config.
The dyngroup definition can be found here : dyngroup.ldif
Then, for the dynamic group feature to work, you need to enable the dynlist overlay, which also need to be defined, see slapo-dynlist.
You can refer to this issue as a kind of walk through.
I'm trying to figure out if FeathersJS suits my needs. I have looked at several examples and use cases. FeathersJS uses a set of request methods : find, get, create, update, patch and delete. No other methods let alone custom methods can be implemented and used, as confirmed on this other SO post..
Let's imagine this application where users can save their app settings. Careless of following method conventions, I would create an endpoint describing the action that is performed by the user. In this case, we could have, for instance: /saveSettings. Knowing there won't be any setting-finding, -creation, -updating (only some -patching) or -deleting. I might also need a /getSettings route.
My question is: can every action be reduced down to these request methods? To me, these actions are strongly bound to a specific collection/model. Sometimes, we need to create actions that are not bound to a single collection and could potentially interact with more than one collection/model.
For this example, I'm guessing it would be translated in FeathersJS with a service named Setting which would hold two methods: get() and a patch().
If that is the correct approach, it looks to me as if this solution is more server-oriented than client-oriented in the sense that we have to know, client-side, what underlying collection is going to get changed or affected. It feels like we are losing some level of freedom by not having some kind of routing between endpoints and services (like we have in vanilla ExpressJS).
Here's another example: I have a game character that can skill-up. When the user decides to skill-up a particular skill, a request is sent to the server. This endpoint can look like POST: /skillUp What would it be in FeathersJS? by implementing SkillUpService#create?
I hope you get the issue I'm trying to highlight here. Do you have some ideas to share or recommendations on how to organize the API in this particular framework?
I'm not an expert of featherJs, but if you build your database and models with a good logic,
these methods are all you need :
for the settings example, saveSettings corresponds to setting.patch({options}) so to the route settings/:id?options (method PATCH) since the user already has some default settings (created whith the user). getSetting would correspond to setting.find(query)
To create the user AND the settings, I guess you have a method to call setting.create({defaultOptions}) when the user CREATE route is called. This would be the right way.
for the skillUp route, depends on the conception of your database, but I guess it would be something like a table that gives you the level/skills/character, so you need a service for this specific table and to call skillLevel.patch({character, level})
In addition to the correct answer that #gui3 has already given, it is probably worth pointing out that Feathers is intentionally restricting in order to help you create RESTful APIs which focus on resources (data) and a known set of methods you can execute on them.
Aside from the answer you linked, this is also explained in more detail in the FAQ and an introduction to REST API design and why Feathers does what it does can be found in this article: Design patterns for modern web APIs. These are best practises that helped scale the internet (specifically the HTTP protocol) to what it is today and can work really well for creating APIs. If you still want to use the routes you are suggesting (which a not RESTful) then Feathers is not the right tool for the job.
One strategy you may want to consider is using a request parameter in a POST body such as { "action": "type" } and use a switch statement to conditionally perform the desired action. An example of this strategy is discussed in this tutorial.
Configuration for a particular spinnaker system can be written in a number of different files. Is precedence documentation available?
e.g. for clouddriver:
/opt/spinnaker/config/clouddriver.yml
/opt/spinnaker/config/clouddriver-local.yml
/opt/clouddriver/config/clouddriver.yml
or settings can be in the provider section of
/opt/spinnaker/config/spinnaker-local.yml
I wrote a blog post on this very topic a while back, because several users were getting confused:
https://www.travistomsu.com/2016/12/19/configuring-spinnaker/
The gist is that there are various levels of shared settings (with overrides) and service-specific settings (with overrides).
The order of loading looks like:
spinnaker.yaml (shared across all services, do not edit - will be overwritten on update)
spinnaker-local.yaml (override across all services, editable)
service.yaml (service-specific, do not edit)
service-local.yaml (override for this particular service, editable)
As per my comment I found the documentation here
Based on that, even though there is no mention of /opt/subsystem/config/subsystem.yml I will go with using /opt/spinnaker/config/clouddriver-local.yml
I'm writing functional test and having difficulty mocking http:request-config with oauth2. It failed at requesting for token. I tried moving the config to a separate file and create a different config in src/test/resources and include only the test config when testing. Now it complains about "name must be unique" - how do I get around this?
Be sure that your getConfigFiles() override does not include the configuration file that contains the original . This means it will need to be in a separate file from the one containing the flow you are testing.
Another method is to use a mock HTTP server such as sham-http.
In order to test Mule application you can use MUnit:
http://developer.mulesoft.com/docs/display/current/MUnit
It will allow you to mock message processors.
Now, config elements are top level elements. Those can not be mock.
I would suggest you take a look to documentation to see if the tool fit your needs.
HTH
My application needs to be able to serve up static content which can be contained in a number of different places (directories and/or via the class loader). So, for example, a resource /static/file.html might be found in /dir1/file.html or /dir2/file.html; I would want it to try /dir1, and if not found there, then /dir2, and so on.
With servlets in Jetty, I can use either a HandlerList of DefaultServlet, to sequentially try to handle the request from each directory until satisfied, or even easier a single DefaultServlet with a ResourceCollection.
I can't see a way to do something similar in restlet, without writing a class to specifically do this. I could modify Directory to handle multiple sources (in a similar way to DefaultServlet with ResourceCollection), or write a new Restlet which tries each contained Restlet sequentially, until successfully handled (like HandlerList). But before I do that, am I missing another way that already exists to achieve this?
thanks,
Stuart
I confirm that Directory doesn't know how to handle multiple source directories. It would be a nice to add support for this and contribute it back.