[jira] Updated: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-92: --- Attachment: move-to-maven-acf-framework.patch This is a first go on moving to maven. I started refactoring the framework part. This should give a good idea of what is possible. Of course we are nog there. I did not really touch any of the scripts. There is also one dependency you have to install locally. You'll see it when you try to run maven. Advice on ho to install it locally is provided when it fails. I am not sure if this patch will run, it is a big one. Hope for the best When the patch is successfully applied, go to the modules/framework folder and try: mvn clean install then step into crawler-ui and do mvn clean jetty:run-war Use you browser to go to localhost:8080 and you can see the crawler-ui web app. If you connect to an existing database, you should be able to see the configure connections lists. Not more than that, than we need to put the connectors on the classpath. I'd be happy to do something similar for the connectors. But than we must be sure that this is the way to go. It takes a lot of time. Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Attachments: move-to-maven-acf-framework.patch, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902805#action_12902805 ] Karl Wright commented on CONNECTORS-92: --- It looks to me like you adopted the one-jar-per-maven-script approach, with no coalescing of jars, but instead introducing /src/main under each of the subtargets within framework. I'd really like instead to make our job easier by at least combining the framework main jars together into one target first, along the lines I described above. I'd also like to get a sense of the overall picture before proceeding, so can we discuss what individual maven targets there are that you are proposing, and what each of them is, before we undertake any changes of this kind? The individual connector ones are obvious, but I'm concerned about stuff like the integration tests and the quick-start jetty package. How do you cover those in a maven build? Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Attachments: move-to-maven-acf-framework.patch, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About name change
On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and the late response from people on gene...@. Obviously we need to decide on something else than Apache Connectors Framework since many people had concerns about the name and possible confusion. I have the impression we should first collect some suggestions about alternative names here before we continue discussion on the gene...@. Once we have a name we all agreed on and doesn't apply to the concerns others had we should go back and discuss further. Some folks suggested a more abstract name like Apache Connecto which I personally like (not necessarily Connecto but a more abstract name. Such names have many advantages as people remember short names and they are less ambiguous. Any suggestions, thoughts? simon -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8
Re: About name change
On Thu, Aug 26, 2010 at 12:42 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Absolutely +1 - I just have the impression that people are already biased by Tomcat Connector etc. but I will be a supporter of Apache Connector FW, no doubt. If it is not an option we can still discuss here! simon Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and the late response from people on gene...@. Obviously we need to decide on something else than Apache Connectors Framework since many people had concerns about the name and possible confusion. I have the impression we should first collect some suggestions about alternative names here before we continue discussion on the gene...@. Once we have a name we all agreed on and doesn't apply to the concerns others had we should go back and discuss further. Some folks suggested a more abstract name like Apache Connecto which I personally like (not necessarily Connecto but a more abstract name. Such names have many advantages as people remember short names and they are less ambiguous. Any suggestions, thoughts? simon -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8
[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902834#action_12902834 ] Jettro Coenradie commented on CONNECTORS-92: Very cool Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Attachments: move-to-maven-acf-framework.patch, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902838#action_12902838 ] Robert Muir commented on CONNECTORS-92: --- I am the last person to comment about maven, but i noticed tika has a maven build that builds a large single jar that contains all classes from dependencies Perhaps it would be a useful example if you want to do this 'jar coalescing' Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Attachments: move-to-maven-acf-framework.patch, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CONNECTORS-95) add svn:ignore properties for files that shouldnt be committed
[
https://issues.apache.org/jira/browse/CONNECTORS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir reassigned CONNECTORS-95:
-
Assignee: Robert Muir
add svn:ignore properties for files that shouldnt be committed
--
Key: CONNECTORS-95
URL: https://issues.apache.org/jira/browse/CONNECTORS-95
Project: Apache Connectors Framework
Issue Type: Task
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Attachments: CONNECTORS-95.patch
I noticed after running tests and a few other ant tasks that lots of files
showed up in 'svn status'.
I think it would be good to add svn:ignores to prevent any of these from
being accidentally committed
This is what 'svn status' shows for me:
{noformat}
? .project
? bin
? modules\build
? modules\test-output
? modules\connectors\filesystem\build
? modules\connectors\filesystem\dist
? modules\connectors\filesystem\doc
? modules\connectors\filesystem\lib
? modules\connectors\filesystem\test-output
? modules\connectors\nulloutput\build
? modules\connectors\nulloutput\dist
? modules\connectors\nulloutput\doc
? modules\connectors\nulloutput\lib
? modules\connectors\sharepoint\lib
? modules\framework\build
? modules\framework\dist
? modules\framework\doc
? modules\framework\lib
? modules\framework\test-output
? modules\framework\crawler-ui\WEB-INF\web-generated.xml
{noformat}
The .project and bin are from eclipse, but these (and any files ides like
IDEA generate) are probably good candidates also.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: About name change
Personally, I'd rather see a traditional, Apache-style name, but I can certainly live with whatever the PMC (?) endorses. I agree with the general@ criticism that the ACF name comes across as being the ultimate end-all connector framework for Apache land (land grab). We should acknowledge that in the future there might be other projects that seek to offer connector frameworks in Apache land. There really should be a handle to qualify the purely descriptive portion of the name - and we had one: Lucene, but it wasn't unique and even there did not acknowledge that in the future there could be other connector frameworks. Note: We effectively have a handle name today: LCF or ACF, but it is a distinctly non-Apache style of name. Why not go with an Apache-style name. That said, I do see that there are a minority of Apache Projects that have descriptive names, including HttpComponents, OpenWebBeans, TrafficServer, Web Services, XML Graphics. Well, there is also HTTP Server as well, but that is an anomaly since it is really just the original Apache itself. Maybe the question is what the current consensus preference is in Apache land and trying to go with the flow rather than try to go against the flow. In short, even if Connectors Framework remains the tail end of the name, a handle prefix is needed. Apache is the general prefix for ALL Apache projects and not a handle for any of them. If that handle is Connecto, the full name could be Connecto Connectors Framework, and the official project name would be Apache Connecto Connectors Framework. That said, I am not a fan of trying to put the project description into the name in raw English form. So, my preference there would be to drop Connectors Framework from the name and stick with Connecto, or whatever other handle is chosen. As I said, I will defer to the PMC (?) endorses, but I would hope that there is some consistency with current and traditional Apache project naming conventions. -- Jack Krupansky -- From: Simon Willnauer simon.willna...@googlemail.com Sent: Thursday, August 26, 2010 7:50 AM To: Grant Ingersoll gsing...@apache.org Cc: connectors-dev@incubator.apache.org Subject: Re: About name change On Thu, Aug 26, 2010 at 12:42 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Absolutely +1 - I just have the impression that people are already biased by Tomcat Connector etc. but I will be a supporter of Apache Connector FW, no doubt. If it is not an option we can still discuss here! simon Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and the late response from people on gene...@. Obviously we need to decide on something else than Apache Connectors Framework since many people had concerns about the name and possible confusion. I have the impression we should first collect some suggestions about alternative names here before we continue discussion on the gene...@. Once we have a name we all agreed on and doesn't apply to the concerns others had we should go back and discuss further. Some folks suggested a more abstract name like Apache Connecto which I personally like (not necessarily Connecto but a more abstract name. Such names have many advantages as people remember short names and they are less ambiguous. Any suggestions, thoughts? simon -- Grant Ingersoll http://lucenerevolution.org Lucene/Solr Conference, Boston Oct 7-8
[jira] Commented: (CONNECTORS-97) Web connector session authentication fails for some sites due to cookies httpclient says are illegal, but browsers accept
[ https://issues.apache.org/jira/browse/CONNECTORS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902880#action_12902880 ] Karl Wright commented on CONNECTORS-97: --- It turns out that our version of httpclient does not allow this to be configured. The code in question can be found in the validate() methods in commons-httpclient-3x/src/java/org/apache/httpclient/cookie/: CookieSpecBase.java and RFC2965Spec.java Thus, fixing this problem will require adding a configuration parameter to our httpclient version, as well as changing the web connector to set this configuration parameter appropriately. Web connector session authentication fails for some sites due to cookies httpclient says are illegal, but browsers accept - Key: CONNECTORS-97 URL: https://issues.apache.org/jira/browse/CONNECTORS-97 Project: Apache Connectors Framework Issue Type: Bug Components: Web connector Reporter: Karl Wright While trying to set up session authentication for the site http://www.ppdm.org, I ran into authentication problems that resulted from httpclient rejecting cookies: Cookie rejected: ppdm_forum_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22userid%22%3Bi%3A-1%3B%7D. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_sid=338b5f5f0887ab4c2499948fc05daac8. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A32%3A%2266a33ac80119bdcf7a1129f78de857a1%22%3Bs%3A6%3A%22userid%22%3Bs%3A4%3A%221346%22%3B%7D. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_sid=3c36d20f96423b2de2d215a33b304e18. Illegal path attribute /forums. Path of origin: /ba/login/login And yet, FireFox and IE have no trouble with these. I suspect that there must be a configuration setting for httpclient that will fix this problem - and if there isn't, we need to add one and set it appropriately in the web connector code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\} would
be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some might
desire. It would be better to take care of this before the initial release so
that we never have to answer the question of why it wasn't done as a proper
RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can process
the DELETE and PUT methods (using the doDelete and doPut method overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-56) All features should be accessible through an API
[ https://issues.apache.org/jira/browse/CONNECTORS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902940#action_12902940 ] Mark Miller commented on CONNECTORS-56: --- bq. HTTP methods other than GET or PUT are in fact poorly supported in many HTTP clients, including Apache Commons HTTPClient. That's untrue. bq. I am also unsure of whether Jetty supports the DELETE method at the servlet level. Jetty has no issues with DELETE, POST, PUT, or GET. Nor does Tomcat or any other container I have seen. bq. I therefore think your suggestion would potentially cause a great deal of headache for no tangible benefit. Again, I don't agree - it would cause less headaches, as REST is somewhat of a standard rather than an ad hoc api. There are many advantages to having a consistent RESTful api. All features should be accessible through an API Key: CONNECTORS-56 URL: https://issues.apache.org/jira/browse/CONNECTORS-56 Project: Apache Connectors Framework Issue Type: Sub-task Components: Framework core Reporter: Jack Krupansky Assignee: Karl Wright LCF consists of a full-featured crawling engine and a full-featured user interface to access the features of that engine, but some applications are better served with a full API that lets the application control the crawling engine, including creation and editing of connections and creation, editing, and control of jobs. Put simply, everything that a user can accomplish via the LCF UI should be doable through an LCF API. All LCF objects should be queryable through the API. A primary use case is Solr applications which currently use Aperture for crawling, but would prefer the full-featured capabilities of LCF as a crawling engine over Aperture. I do not wish to over-specify the API in this initial description, but I think the LCF API should probably be a traditional REST API., with some of the API elements specified via the context path, some parameters via URL query parameters, and complex, detailed structures as JSON (or similar.). The precise details of the API are beyond the scope of this initial description and will be added incrementally once the high-level approach to the API becomes reasonably settled. A job status and event reporting scheme is also needed in conjunction with the LCF API. That requirement has already been captured as CONNECTORS-41. The intention for the API is to create, edit, access, and control all of the objects managed by LCF. The main focus is on repositories, jobs, and status, and less about document-specific crawling information, but there may be some benefit to querying crawling status for individual documents as well. Nothing in this proposal should in any way limit or constrain the features that will be available in the LCF UI. The intent is that LCF should continue to have a full-featured UI, but in addition to a full-featured API. Note: This issue is part of Phase 2 of the CONNECTORS-50 umbrella issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902941#action_12902941
]
Mark Miller commented on CONNECTORS-98:
---
bq. Also, POST should be usable as an alternative to PUT for API calls that
have large volumes of data.
That shouldn't be necessary at all.
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONNECTORS-97) Web connector session authentication fails for some sites due to cookies httpclient says are illegal, but browsers accept
[ https://issues.apache.org/jira/browse/CONNECTORS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-97. --- Fix Version/s: LCF Release 0.5 Resolution: Fixed r989844-r989847 Web connector session authentication fails for some sites due to cookies httpclient says are illegal, but browsers accept - Key: CONNECTORS-97 URL: https://issues.apache.org/jira/browse/CONNECTORS-97 Project: Apache Connectors Framework Issue Type: Bug Components: Web connector Reporter: Karl Wright Assignee: Karl Wright Fix For: LCF Release 0.5 While trying to set up session authentication for the site http://www.ppdm.org, I ran into authentication problems that resulted from httpclient rejecting cookies: Cookie rejected: ppdm_forum_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22userid%22%3Bi%3A-1%3B%7D. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_sid=338b5f5f0887ab4c2499948fc05daac8. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A32%3A%2266a33ac80119bdcf7a1129f78de857a1%22%3Bs%3A6%3A%22userid%22%3Bs%3A4%3A%221346%22%3B%7D. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_sid=3c36d20f96423b2de2d215a33b304e18. Illegal path attribute /forums. Path of origin: /ba/login/login And yet, FireFox and IE have no trouble with these. I suspect that there must be a configuration setting for httpclient that will fix this problem - and if there isn't, we need to add one and set it appropriately in the web connector code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CONNECTORS-97) Web connector session authentication fails for some sites due to cookies httpclient says are illegal, but browsers accept
[ https://issues.apache.org/jira/browse/CONNECTORS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reassigned CONNECTORS-97: - Assignee: Karl Wright Web connector session authentication fails for some sites due to cookies httpclient says are illegal, but browsers accept - Key: CONNECTORS-97 URL: https://issues.apache.org/jira/browse/CONNECTORS-97 Project: Apache Connectors Framework Issue Type: Bug Components: Web connector Reporter: Karl Wright Assignee: Karl Wright Fix For: LCF Release 0.5 While trying to set up session authentication for the site http://www.ppdm.org, I ran into authentication problems that resulted from httpclient rejecting cookies: Cookie rejected: ppdm_forum_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22userid%22%3Bi%3A-1%3B%7D. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_sid=338b5f5f0887ab4c2499948fc05daac8. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A32%3A%2266a33ac80119bdcf7a1129f78de857a1%22%3Bs%3A6%3A%22userid%22%3Bs%3A4%3A%221346%22%3B%7D. Illegal path attribute /forums. Path of origin: /ba/login/login Cookie rejected: ppdm_forum_sid=3c36d20f96423b2de2d215a33b304e18. Illegal path attribute /forums. Path of origin: /ba/login/login And yet, FireFox and IE have no trouble with these. I suspect that there must be a configuration setting for httpclient that will fix this problem - and if there isn't, we need to add one and set it appropriately in the web connector code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902982#action_12902982
]
Jack Krupansky commented on CONNECTORS-98:
--
Karl asks what do you plan to do for the list and execute verbs?
List would be a GET and execute would be PUT.
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902983#action_12902983
]
Jack Krupansky commented on CONNECTORS-98:
--
Karl says I await your patch.
Point well made. There is a great starting point with the current code. A bit
of refactoring required.
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903151#action_12903151 ] Karl Wright commented on CONNECTORS-92: --- I rearranged the framework part of the tree to what I believe will satisfy maven. The rest of the tree I will cover in a subsequent check-in, provided I got this part right. Can you verify that the current tree is correct, and can you upload a new maven patch based on the new tree? Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Attachments: move-to-maven-acf-framework.patch, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
