You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Vivek Alampally <vi...@gmail.com> on 2011/06/27 15:47:41 UTC

java.lang.NoSuchMethodError Exception While Using Apache CXF 2.4 and wss4j 1.5.11

Hi
I am getting the following exception while replacing existing cxf 2.3.3 jar
with Apache CXF 2.4.1
java.lang.NoSuchMethodError<http://download.oracle.com/javase/6/docs/api/java/lang/NoSuchMethodError.html>:
org.apache.ws.security.util.WSSecurityUtil.decodeAction(Ljava/lang/String;Ljava/util/List;)I

Can anyone please tell me whether there are any compatibility issues
with Apache CXF 2.4 and wss4j 1.5.11.

Re: A question of choice

Posted by Glen Mazza <gm...@talend.com>.

On 06/27/2011 10:53 AM, David Sills wrote:
> So now the questions:
>
> 1. Can or should this service be converted to REST?
> 2. Can it be converted to REST as is, or should it be broken up into
> smaller pieces (not sure the client would agree to that)?
> 3. Can REST handle the amount of data a GET request would necessarily
> have to include?
>
> Any ideas? Any tales of converting something like this and the ups and
> downs you encountered?
>

Only thing I can add is my blog entry on using FOP with web services, 
which might be of help for you in a non-REST situation:
http://www.jroller.com/gmazza/entry/using_mtom_and_apache_fop

Also, for the print generation logic, perhaps some of the source code 
for Kohmori, the World's Least Used Report Generation System, *could* 
provide a pointer or two: 
http://www.jroller.com/gmazza/entry/kohmori_reports_now_using_jaxb

HTH,
Glen

> Thanks in advance!
>
> David Sills
>


-- 
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza

RE: A question of choice

Posted by David Sills <DS...@datasourceinc.com>.

Thanks, Sergey, I'll give these suggestions some thought. I agree there
is probably some refactoring involved, but for the moment the client is
happy with the performance of the service and with the simplicity of the
API from their client code's point of view (of course, that simply means
the service has to do more with parameters). The tradeoffs between more
thoroughly refactored API (and happier developers) and greater
complexity in the application client don't for the present appear to
appeal, but that's a stone at which I can continue to chip.

Warmly,

David


------------------------------------------------------------------------
---

>If one have so many input parameters that they can't fit into GET
>query then it's a sign the refactoring of the service URI space is
>really needed.

Re: A question of choice

Posted by Sergey Beryozkin <sb...@gmail.com>.

Hi

On Mon, Jun 27, 2011 at 3:53 PM, David Sills <DS...@datasourceinc.com> wrote:
> All:
>
> A question for designers out there who wish to opine on best practices
> or advise me about an upcoming issue: we have an essentially RPC web
> service being considered for conversion to a RESTful one. Apologies for
> the length of the post before it even begins:
>
> The current SOAP web service, among other things, generates PDF reports
> (using BIRT behind the scenes, although of course that could be swapped
> out, which was the idea). A report can have arbitrarily many parameters
> (and many have quite a few) that must be supplied. In addition, the
> service performs a number of other functions are currently executed
> within a single service call. For instance, the service may print the
> generated document, keep it for later retrieval, or save it to a
> database. It may retrieve a document from the database rather than
> generating it.
>
> At the moment, what the service does is governed by a DocumentMetadata
> object:
>
> public interface DocumentMetadata
> {
>        String getDesignFilename();
>        String getAssociatedCaseId();
>        String getDocumentItemPageId();
>        String getTitleToSaveAs();
>        boolean isKeepAfterProcessing();
> }
>
> This allows the client to specify the name of the report file to use in
> generation, the case to which the document should be associated (a
> one-to-many relationship), the database ID of the document, the title to
> save the document as, and whether or not to keep it available.
>
> Another object (PrintJob) sent along details print parameters (printer
> to use, number of copies, orientation, etc.).
>
> The service uses these to decide what to do:
>
> 1. If the designFilename is supplied, a report is generated.
> 2. If the documentItemPageId is supplied, the report is retrieved from
> the database.
> 3. If the titleToSaveAs is supplied, the report is saved to the database
> with the appropriate title in addition to the bytes of the report itself
> (all saved documents require titles).
> 4. If the report is saved to the database and the associatedCaseId is
> supplied, a foreign-key reference to the case is inserted along with the
> document record (documents may relate to cases or not [e.g., summaries
> of daily activity relate to no specific case]).
> 5. If the keepAfterProcessing is set to true, the document is saved and
> information about how to retrieve it is returned to the client.
> 6. If the print object is supplied (non-null), the document (however
> obtained) is printed following the supplied parameters or sensible
> defaults.
>
> What is returned to the client is a ProcessingOutcome object:
>
> public interface ProcessingOutcome
> {
>        boolean isReportCreationSuccessful();
>        String getDocumentId();
>        String getDocumentItemId();
>        String getDocumentItemPageId();
>        boolean isPrintingSuccessful();
>        String getUrl();
>        String getUnc();
> }
>
> Most of this is obvious:
>
> 1. Whether report creation was successful (false if the report was
> retrieved from the database)
> 2. The various database IDs associated with the document (don't even ask
> - I didn't design the database, obviously)
> 3. Whether or not printing was successful (false if it was not
> requested)
> 4. If the document was kept, a URL for retrieving it via HTTP and a UNC
> reference for retrieving it via Windows Explorer et alia
>
> So now the questions:
>
> 1. Can or should this service be converted to REST?

I don't see immediate issues which would prevent it from being converted

> 2. Can it be converted to REST as is, or should it be broken up into
> smaller pieces (not sure the client would agree to that)?

Here are some observations. I'd avoid specifying an id upfront and let
server allocate it for new PDFs.
This can minimize a number of parameters. LIkewise, rather than
'leaking' a DB id, return opaque URI
which will protect the consumer from the likely DB changes which may follow.
You can get it split in two pieces, one (controller) will deal with DB
(via indirection if needed), etc, and then you can get another
component, possibly not even JAX-RS one, which will specifically
handle the conversion of in Data into PDF.
When consumer requests a new PDF the controller can also do some
preparation work and redirect the consumer to a dedicated resource
which will provide the actual PDF. This will make the experience
smoother a bit for a client.
Supporting multipart/form-data should also help with the browser
asking the user where PDF needs to be saved...

> 3. Can REST handle the amount of data a GET request would necessarily
> have to include?
>
If one have so many input parameters that they can't fit into GET
query then it's a sign the refactoring of the service URI space is
really needed.

Cheers, Sergey

> Any ideas? Any tales of converting something like this and the ups and
> downs you encountered?
>
> Thanks in advance!
>
> David Sills
>
>



-- 
Sergey Beryozkin

Application Integration Division of Talend
http://sberyozkin.blogspot.com

Re: A question of choice

Posted by Sergey Beryozkin <sb...@gmail.com>.

HI

Thanks for this info, I'll try to get back to later during the next few days
Cheers, Sergey

On Mon, Jun 27, 2011 at 3:53 PM, David Sills <DS...@datasourceinc.com> wrote:
> All:
>
> A question for designers out there who wish to opine on best practices
> or advise me about an upcoming issue: we have an essentially RPC web
> service being considered for conversion to a RESTful one. Apologies for
> the length of the post before it even begins:
>
> The current SOAP web service, among other things, generates PDF reports
> (using BIRT behind the scenes, although of course that could be swapped
> out, which was the idea). A report can have arbitrarily many parameters
> (and many have quite a few) that must be supplied. In addition, the
> service performs a number of other functions are currently executed
> within a single service call. For instance, the service may print the
> generated document, keep it for later retrieval, or save it to a
> database. It may retrieve a document from the database rather than
> generating it.
>
> At the moment, what the service does is governed by a DocumentMetadata
> object:
>
> public interface DocumentMetadata
> {
>        String getDesignFilename();
>        String getAssociatedCaseId();
>        String getDocumentItemPageId();
>        String getTitleToSaveAs();
>        boolean isKeepAfterProcessing();
> }
>
> This allows the client to specify the name of the report file to use in
> generation, the case to which the document should be associated (a
> one-to-many relationship), the database ID of the document, the title to
> save the document as, and whether or not to keep it available.
>
> Another object (PrintJob) sent along details print parameters (printer
> to use, number of copies, orientation, etc.).
>
> The service uses these to decide what to do:
>
> 1. If the designFilename is supplied, a report is generated.
> 2. If the documentItemPageId is supplied, the report is retrieved from
> the database.
> 3. If the titleToSaveAs is supplied, the report is saved to the database
> with the appropriate title in addition to the bytes of the report itself
> (all saved documents require titles).
> 4. If the report is saved to the database and the associatedCaseId is
> supplied, a foreign-key reference to the case is inserted along with the
> document record (documents may relate to cases or not [e.g., summaries
> of daily activity relate to no specific case]).
> 5. If the keepAfterProcessing is set to true, the document is saved and
> information about how to retrieve it is returned to the client.
> 6. If the print object is supplied (non-null), the document (however
> obtained) is printed following the supplied parameters or sensible
> defaults.
>
> What is returned to the client is a ProcessingOutcome object:
>
> public interface ProcessingOutcome
> {
>        boolean isReportCreationSuccessful();
>        String getDocumentId();
>        String getDocumentItemId();
>        String getDocumentItemPageId();
>        boolean isPrintingSuccessful();
>        String getUrl();
>        String getUnc();
> }
>
> Most of this is obvious:
>
> 1. Whether report creation was successful (false if the report was
> retrieved from the database)
> 2. The various database IDs associated with the document (don't even ask
> - I didn't design the database, obviously)
> 3. Whether or not printing was successful (false if it was not
> requested)
> 4. If the document was kept, a URL for retrieving it via HTTP and a UNC
> reference for retrieving it via Windows Explorer et alia
>
> So now the questions:
>
> 1. Can or should this service be converted to REST?
> 2. Can it be converted to REST as is, or should it be broken up into
> smaller pieces (not sure the client would agree to that)?
> 3. Can REST handle the amount of data a GET request would necessarily
> have to include?
>
> Any ideas? Any tales of converting something like this and the ups and
> downs you encountered?
>
> Thanks in advance!
>
> David Sills
>
>



-- 
Sergey Beryozkin

Application Integration Division of Talend
http://sberyozkin.blogspot.com

A question of choice

Posted by David Sills <DS...@datasourceinc.com>.

All:

A question for designers out there who wish to opine on best practices
or advise me about an upcoming issue: we have an essentially RPC web
service being considered for conversion to a RESTful one. Apologies for
the length of the post before it even begins:

The current SOAP web service, among other things, generates PDF reports
(using BIRT behind the scenes, although of course that could be swapped
out, which was the idea). A report can have arbitrarily many parameters
(and many have quite a few) that must be supplied. In addition, the
service performs a number of other functions are currently executed
within a single service call. For instance, the service may print the
generated document, keep it for later retrieval, or save it to a
database. It may retrieve a document from the database rather than
generating it.

At the moment, what the service does is governed by a DocumentMetadata
object:

public interface DocumentMetadata
{
	String getDesignFilename();
	String getAssociatedCaseId();
	String getDocumentItemPageId();
	String getTitleToSaveAs();
	boolean isKeepAfterProcessing();
}

This allows the client to specify the name of the report file to use in
generation, the case to which the document should be associated (a
one-to-many relationship), the database ID of the document, the title to
save the document as, and whether or not to keep it available.

Another object (PrintJob) sent along details print parameters (printer
to use, number of copies, orientation, etc.).

The service uses these to decide what to do:

1. If the designFilename is supplied, a report is generated.
2. If the documentItemPageId is supplied, the report is retrieved from
the database.
3. If the titleToSaveAs is supplied, the report is saved to the database
with the appropriate title in addition to the bytes of the report itself
(all saved documents require titles).
4. If the report is saved to the database and the associatedCaseId is
supplied, a foreign-key reference to the case is inserted along with the
document record (documents may relate to cases or not [e.g., summaries
of daily activity relate to no specific case]).
5. If the keepAfterProcessing is set to true, the document is saved and
information about how to retrieve it is returned to the client.
6. If the print object is supplied (non-null), the document (however
obtained) is printed following the supplied parameters or sensible
defaults.

What is returned to the client is a ProcessingOutcome object:

public interface ProcessingOutcome
{
	boolean isReportCreationSuccessful();
	String getDocumentId();
	String getDocumentItemId();
	String getDocumentItemPageId();
	boolean isPrintingSuccessful();
	String getUrl();
	String getUnc();
}

Most of this is obvious: 

1. Whether report creation was successful (false if the report was
retrieved from the database)
2. The various database IDs associated with the document (don't even ask
- I didn't design the database, obviously)
3. Whether or not printing was successful (false if it was not
requested)
4. If the document was kept, a URL for retrieving it via HTTP and a UNC
reference for retrieving it via Windows Explorer et alia

So now the questions:

1. Can or should this service be converted to REST?
2. Can it be converted to REST as is, or should it be broken up into
smaller pieces (not sure the client would agree to that)?
3. Can REST handle the amount of data a GET request would necessarily
have to include?

Any ideas? Any tales of converting something like this and the ups and
downs you encountered?

Thanks in advance!

David Sills