The documentation for the resteasy.use.builtin.providers configuration switch reads:
Whether or not to register default, built-in #Provider classes.
I have set that to false to use my own (GWT) JSON format, but would like to know what i am missing or if is there anyone i should not exclude.
So, what are the built-in #Provider classes in Resteasy, or how can i find them?
I don't know a documentation for that. Best way may be to search in the sources.
If you are only using resteasy-jaxrs you can find these providers in the master-branch:
* org.jboss.resteasy.client.exception.mapper.ApacheHttpClient4ExceptionMapper
* org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter
* org.jboss.resteasy.plugins.interceptors.encoding.AcceptEncodingGZIPFilter
* org.jboss.resteasy.plugins.interceptors.encoding.AcceptEncodingGZIPInterceptor
* org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor
* org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor
* org.jboss.resteasy.plugins.providers.DataSourceProvider
* org.jboss.resteasy.plugins.providers.DefaultTextPlain
* org.jboss.resteasy.plugins.providers.DocumentProvider
* org.jboss.resteasy.plugins.providers.FileProvider
* org.jboss.resteasy.plugins.providers.FormUrlEncodedProvider
* org.jboss.resteasy.plugins.providers.IIOImageProvider
* org.jboss.resteasy.plugins.providers.InputStreamProvider
* org.jboss.resteasy.plugins.providers.JaxrsFormProvider
* org.jboss.resteasy.plugins.providers.ReaderProvider
* org.jboss.resteasy.plugins.providers.SerializableProvider
* org.jboss.resteasy.plugins.providers.SourceProvider
* org.jboss.resteasy.plugins.providers.StringTextStar
This are the classes annotated with #Provider. Mostly the same are registered in META-INF/services/ javax.ws.rs.ext.Providers.
But I'm not sure why you want to do disable them. AFAIK if you register a #Provider which #Produces(MediaType.APPLICATION_JSON) or #Consumes(MediaType.APPLICATION_JSON) the default one will be ignored.
Related
When using /** in Eclipse (or in my case OnSemi IDE -- based on Eclipse), it will autocomplete when pressing enter to create a comment that (with Doxygen and Javadocs enabled) fills in the Javadoc tags to look something like:
/**
* #brief
*
* #param a
* #param b
*/
void foo(int a, bool b)
What I have been unable to figure out is how to update this autocomplete to add "border" to the comment. The goal would look like:
/******************************************************************************
* #brief
*
* #param a
* #param b
******************************************************************************/
void foo(int a, bool b)
Note: I would hope these "borders" would ONLY occur when applied to method comments, rather than internal comments within code (when adding a large, multi-line comment, we use /** for this occasionally).
I've tried going to Window->Preferences->C/C++->Code Style->Code Templates and adjusting the comments templates without success.
Is it somehow possible in Doxygen to create a custom tag, which creates a documentation using a placeholder tag as its input?
What I want to accomplish is to create a custom tag for requirements. As our DOORS Urls are quite long, and diverge from SW-component to SW-component, I want to create something similar to this:
#file somefile.c
#doorsdocurl <URL to DOORS document> -> this is going to be my placeholder
...
...
...
/**
* #brief somedescription
* #req{doorsdocurl: <reqID1, reqID2,...> } -> this is going to be the second custom tag
*/
void jambo()
{
}
Is this somehow achievable with Doxygen? From what I have read, one has to put his custom tags within the ALIASES variable
In your Doxyfile you would need something like:
ALIASES = "doorsdocurl_sw_1=<URL to DOORS document>" \
"req{2}=\1 \2<br>"
and the code would look like:
/**
* #brief somedescription
*
* #req{#doorsdocurl_sw_1,reqID1}
* #req{#doorsdocurl_sw_1,reqID2}
*/
void jambo()
{
}
The \req command can of course be extended with other commands, in this respect the command xrefitem might be useful, see the manual (http://www.doxygen.nl/manual/commands.html#cmdxrefitem)
I have a maybe simple problem, but my Google-Fu produced no results.
I have a doxygen documented header file like this:
/**
* #file filename.h
*
* #date today
* #author me
*
* #defgroup mygroup grouptitle
* #brief my nice functions
*
* Here is a medium sized description, 4-5 lines, which outline the
* functions and the way these functions work together, what is init,
* what is the main function of this module and maybe additional
* information on used hardware (as it is mainly embedded software).
*
* Here starts another description block, typical length around 20-50
* lines. Detailed Hardware description, code snippets as examples and
* so on. I want to remove this section from the header file and
* replace it by something like
* /special_doyxgen_command_to_insert extended_doc_mygroup.md
*
* \addtogroup mygroup
* #{
*/
here are function definitions, enums, defines and what else
/** #} */
I have no idea if this is possible but I have an additional mygroup.md in which some examples are given and and the general usage is shown. Depending on the file it has 10 - 50 lines, mostly 1 or 2 code examples.
In the past I inserted the examples in the header/sourcefiles, but I don't like that approach, so I created a markdown file and linked to this via the doxygen ref functions.
What I would like is a 'insert' tag that inserts the .md contend in the 'Detailed Description' Section of my Group Documentation (the HTML and Latex files).
Is there such a command (or a set of commands to get my approach?)
There are many commands existing to include external code examples in your documentation. Have a look at configuration tag EXAMPLE_PATH and the special commands #include and #snippet. You could create a directory called "examples" where you put your example files into and tell doxygen by entering this directory in the EXAMPLE_PATH tag:
EXAMPLE_PATH = ./examples
Then you create some example files, e.g: examples_1.c
/// [Example1]
/// Here some more text to explain the example which is not shown by the \#snippet command.
// But normal comments are shown as a part of the code
for(;;)
{
doSomething();
}
/// [Example1]
/// [Example2]
while(1)
{
doSomething2();
}
/// [Example2]
Now you can add these code snippets using the #snippet command in your group documentation:
/**
* #defgroup ...
* ...
* #snippet examples_1.c Example1
* ...
* #snippet examples_1.c Example2
*/
Alternatively you can include the code of a whole source file:
/**
* ...
* #include examples_2.c
* ...
*/
Another aprroach you should look at is the usage of the #copydoc and #copydetails command.
Hope this answers your question.
How can I index the C functions for the search engine? E.g. I have the following piece of code documented.
/**
....
* #defgroup MyGroup
*
* #{
*/
/**
* Initialize TCN.
...
*/
int myfunction(void);
...
The myfunction is documented on the HTML under MyGroup. With the search engine I get only the structures not the functions. I'm using the client search engine.
Thanks
Based upon your comment style, you could try to use JAVADOC_AUTOBRIEF = YES to have doxygen interpret the first line within a comment header as a brief description.
You can also set EXTRACT_ALL = YES to have doxygen behave as if all functions are documented even if no documentation is available. It will extract all functions except private class members.
To also include private class members include EXTRACT_PRIVATE = YES
Good luck.
When I read ibatis-sqlmap-2.3.4,I find They both implements SqlMapExecutor.
SqlMapClientImpl do insert with localSqlMapSession which provide thread safe.
But in spring2.5.6, the execute method of SqlMapClientTemplate use SqlMapClientImpl like this:
SqlMapSession session = this.sqlMapClient.openSession();
...
return action.doInSqlMapClient(session);
The openSession method return a new SqlMapSessionImpl each time.
My questions are:
Why SqlMapClientTemplate use sqlMapSeesion instead of sqlMapClient ?
Why localSqlMapSession of sqlMapClient is unused in SqlMapClientTemplate ? use like this:
return action.doInSqlMapClient(this.sqlMapClient);
what's the different between SqlMapClient and SqlMapSeesion ?
for your first question, spring-orm explain in the comment:
// We always need to use a SqlMapSession, as we need to pass a Spring-managed
// Connection (potentially transactional) in. This shouldn't be necessary if
// we run against a TransactionAwareDataSourceProxy underneath, but unfortunately
// we still need it to make iBATIS batch execution work properly: If iBATIS
// doesn't recognize an existing transaction, it automatically executes the
// batch for every single statement...
the answer to difference between ibatis' SqlMapClient and SqlMapSession can be found in interface SqlMapClient's comments:
/**
* Returns a single threaded SqlMapSession implementation for use by
* one user. Remember though, that SqlMapClient itself is a thread safe SqlMapSession
* implementation, so you can also just work directly with it. If you do get a session
* explicitly using this method <b>be sure to close it!</b> You can close a session using
* the sqlMapSession.close() method.
* <p/>
*
* #return An SqlMapSession instance.
*/
public SqlMapSession openSession();