I am using Cups4j and try to figure out, how to use the impressions to send attributes for the job, like colorprint or especially the finisher to staple the printjob.
If i setup the default printsettings # my Docker Cups-server, the settings will be acceptet in every job. i dit this to make sure, my Printer supports it via ipp.
I use this Documentation to get my job-attributes work, but it wont.
attributes.put("finishings", "staple:enum:4");
attributes.put("job-attributes", "finishings:enum:4");
attributes.put("job-attributes", "finishings:enum:4#staple-top-left:boolean:true");
i tried these sets and many more already. Maybe someone can help with it.
The rest of my method looks similar to the cups4j basic usage example.
I have to use the Java library, because its for a microservice-strucure thats already widley implemented.
Thank u!
Related
I want to capture method execution statistics like method name, time taken by method etc in graphite.
We have 8 to 5 products and few of the products are legacy products which are not using spring. So what could be the best way to capture these statistics (in graphite) with very minimal change in the source code.
obviously to use an APM, and in my (opinionated view) the best tool for this is MoSKito:
http://www.moskito.org
If you don't want to change the source code at all: http://blog.anotheria.net/msk/monitoring-existing-application-using-moskito-javaagent/
If you are ok to change the source code slightly:
http://blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-1/
The last link is an example for spring, but it works with AOP annotations, so it should work with any tech you are using (even with ejb).
Last link: if you want to get a look on the tool itself, there is a video on you tube with a webinar held by the apache tomcat community:
https://www.youtube.com/watch?v=5RCkx-hGK1Q
Finally if you happen to live near Montreal, ApacheCon is in Montreal next week and there is a talk about MoSkito there:
https://apachecon.dukecon.org/acna/2018/#/scheduledEvent/0745118b5ee397ec3
best regards
Leon
Check Dropwizard's Metrics library
can i make a "super" feature?
multiple features use the same backgroud steps, can i make them in a different file and run the file instead?
There is no concept of a "super feature file" where you can mention background steps which you can use in other feature files. In Ruby you can call steps from another scenario but it is not supported in Java.
You can achieve your objective by using the Before hook with a tag. In this before hook method you can write up the reusable code. Remember to add the same tag to the desired scenarios and also to run the test with tag in the cucumberoptions.
Big disadvantage of this is the steps are no longer visible in any feature file. You will have to go into the code to find it out, especially problematic if you have folks not familiar or access to your code who are writing scenarios. Guess you can use it if the background steps are technical setup etc.
Lets say you have a background that you want to share which looks something like
Background:
Given foo
And bar
And baz
...
They way to share this is to turn it into a naming problem. All we need to do is give the whole background a single name. In this silly example lets use 'wibble'
Now we can just do
Background:
Given wibble
And implement that (ideally using helper methods) as
Given 'wibble' do
foo
bar
baz
...
end
In doing this you have discovered something that is important to you domain (wibble). You've also solved your problem, and created something that can be used in more complex backgrounds e.g.
Background:
Given wibble
And wobble
The reason there is no 'super feature' is because there is no need for it :)
I am having a restfull service and there are more than 20 clients thats is using this service.
#Path("/provider")
public class Provider{
#Path("/simpleprovider")
#GET
public String getProvider(){
return "Simple Provider";
}
}
Now i have decided to introduce version in service, i have google alot, read my articles but i am totally confused how should i do? suppose i change URI for new service like #Path("/provider/v1") than how should i provide support for existing clients ? by considering this thing should i have to provide change on every client whenever api new version comes in action ?
After Googling i found that there are 3 ways to provide versioning
URL versioning
custom request header
content type
but could not find any practical example please help me in this regard
http://stackoverflow.com/questions/389169/best-practices-for-api-versioning
http://www.narwhl.com/2015/03/the-ultimate-solution-to-versioning-rest-apis-content-negotiation/
http://restcookbook.com/Basics/versioning/
http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html
http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
Any help will be greatly appreciated
Versioning a service can be very tricky and is always a big decision when determining the versioning strategy. Especially if you have people using the service. From my experience here are some things to consider:
Understand and communicate when and if you plan on sun setting versions of your API. The last thing you want to have is a problem where you are having to upkeep 10 different versions of an API.
Understand if a version change is absolutely necessary. A good rule of thumb is if core functionality is changing or if the contract can potentially break someones software that is integrating with your API. Here are some things to consider when determining if you really need to version:
If you are removing fields from a resource.
If you are removing (or updating) a URL (or method).
If an existing endpoint (or method) logic is going to change such that it would require a consumer to re-implement.
Overall, if a change that you make would break someone integrating with your API.
Are you going to require database changes that would not be backwards compatible with your previous version(s)? This is when versioning can get really fun (sarcastically) because now you might have to make your database backwards compatible which, in my experience, can be difficult problem to deal with moving forward.
To answer your question, though, I have found the best way to version to be in the URL. Be very simple and deliberate with your versioning so that it is crystal clear for your integrator. For example:
GET /v1/products/{id} // Version 1
GET /v2/products/{id} // Version 2
** If you decide on URL versioning then my advice is to put do "v" for version and a SINGLE number like 1 or 2. Don't get into versions, sub versions, etc... This will make your API seem like it revs a lot which can cause concern for consumers. Also, keep the version as FAR left of the URL as possible. The idea is that everything to the right of the version is the new versioned resource.
I would AVOID using headers to version your service. You don't want to hide versions from your consumer. Be as transparent and explicit about versioning as you possibly can.
Versioning in the URL allows you to also do some useful routing and things on your web server and proxies as well. You can either version like this in your actual code, for example:
[HttpGet("v1/products")]
public Product GetProduct(string id)
{
return _repository.GetProduct(id);
}
or you can version using your web server by setting up virtual directories (or whatever). Then your code might look something like this instead:
[HttpGet("products")]
public Product GetProduct(string id)
{
return _repository.GetProduct(id);
}
However you decide to version it is very important to think about the pro's and con's of each decision and weigh them because if you are running an API that people are using the bad decisions will catch up to you in a hurry.
http://pastebin.com/5Nvn1uSB this is my xhtml
http://pastebin.com/fqwiRQER this is home there is the code for menuitems that dont work...
http://pastebin.com/Phun7EKS this is registration with connection to db... but doesn't work at all not even running it
Well, I see lots of issues here. First, your description of what's happening is non-existent. It's pretty hard to help you when all you provide is code without a good description of your environment, what you expect to happen and what's actually happening.
Also, it would be helpful to know what steps you have already taken to debug your code.
That said, based on a quick read of your code, your p:commandButton is using an actionListener instead of an action which I believe is the correct attribute.
Lastly, you're using raw text fields from your web page to directly build an SQL statement. This opens you up to all kinds of code injection exploits that you probably want to avoid. You'd be better off using something like JPA as an abstraction layer that allows you to persist objects.
I'm trying to implement both recent suggestions and custom suggesions in global search in the same application. They both use the same path in the provider so it doesn't seem like it is possible to return different results for them. For example just recent searches for suggestions and real search results in the Quick Search Box.
Any idea on how to do this?
Looking at the searchable config document, it looks like you should be able to use different values of android:searchSuggestPath to disambiguate between the two.
This is possible, though it needs a bit of a workaround. I have yet to fully test this on more than one platform, but here is my implementation: Collectionista SearchRecentSuggestionsContentProvider.java
As the recent suggestions are the most restrictive, you have to wrap its provider with the provider needed for the custom suggestions, and make a pass-through for the recent suggestions calls.
It's important that you understand that you do not have to duplicate searchable.xml, nor any of the blocks in the manifest. You use the same authority.
Furthermore, the recent suggestions restrict you to use android:searchSuggestSelection=" ?", so you'll have to deal with that in your provider for custom suggestions queries. You'll want to use android:searchSuggestPath probably, so understand that the queries for recent suggestions arrive at that Uri, and need to be requeried to the path-less Uri.
Both suggestions will be displayed in the same manner as they should be returned via the same cursor.
If you spot any mistakes, would you please be so kind to report them to me?