You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by "weberjn (via GitHub)" <gi...@apache.org> on 2025/04/16 19:24:24 UTC
[PR] Xmlrpc pull-out [jspwiki]
weberjn opened a new pull request, #381:
URL: https://github.com/apache/jspwiki/pull/381
Pulled out the xml-rpc code into a new submodule jspwiki-xmlrpc that is not linked to from the parent pom. So the problems with xml-rpc can be deferred to a later time. I doubt that nowadays anyone use xml-rpc.
Without xml-rpc all tests run and JSPWiki works on apache-tomcat-10.1.39 and wildfly-36.0.0.Final.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jspwiki.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by Murray Altheim <mu...@altheim.com>.
On 11/05/25 00:41, Jürgen Weber wrote:
> which implementation of JAX-RS would you use? Tomcat doesn't bring
> one, and Jersey is quite big, so it shouldn't go into the wiki, should
> it?
>
> One usecase would be to collect on a wiki page things from a tablet or
> the mobile, urls, text snippets or fotos.
>
> I had once played with a servlet to do this, and an Android app to
> send to it, but the servlet no longer works with cors protection.
> https://github.com/weberjn/WikiBag
I'd thought we were going with Jakarta in the upcoming version of JSPWiki,
so I'd assumed we'd use that implementation. But I'm certainly open to
whatever people think, I'm not tied to any one in particular.
Cheers,
Murray
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by Jürgen Weber <we...@gmail.com>.
which implementation of JAX-RS would you use? Tomcat doesn't bring
one, and Jersey is quite big, so it shouldn't go into the wiki, should
it?
One usecase would be to collect on a wiki page things from a tablet or
the mobile, urls, text snippets or fotos.
I had once played with a servlet to do this, and an Android app to
send to it, but the servlet no longer works with cors protection.
https://github.com/weberjn/WikiBag
Am Sa., 10. Mai 2025 um 13:22 Uhr schrieb Juan Pablo Santos Rodríguez
<ju...@gmail.com>:
>
> Oh that be great!! top of my mind, the way we tackle this at work is
> to specify an openapi.yaml file, and we derive the implementation from
> that. Having the spec first has yield us a lot of benefits, but if you
> feel like jumping directly on to the JAX-RS side, it'd be fine for me
> too.
>
> As per the API itself, I guess at least it should contain something
> like login, logout and f.ex., crud for pages (crud for attachments,
> admin, etc. could arrive later on). Everything except login should be
> able to accept some kind of session/login id, be it a header or
> whatever. Ideally, the code from the main jsp files should be
> extracted so it can be reused on the REST api, so that both behave
> equal and fixes can be done on only one place, but I don't know if
> that's feasible.
>
> If I'd be tackling that, all above would mean at least 3 new modules:
> one for the openapi spec, another for the JAX-RS implementation and
> the third one with the code extracted from the JSP files. But that
> would me, approaching it, without having thought on it more than this
> e-mail, so if you come with something different, it'd probably be fine
> too.
>
> WDYT?
>
> cheers,
> juan pablo
>
> On Sat, May 10, 2025 at 4:48 AM Murray Altheim <mu...@altheim.com> wrote:
> >
> > Hi Juan Pablo,
> >
> > I know I haven't been very active for a long time in terms of contributing
> > code (lots has happened at this end), but if I had a basic specification
> > of what was expected I could probably build out a RESTful API for JSPWiki
> > reasonably quickly (depending on whether or not there are any gotchas in
> > the specification), and would be interested in doing so as it'd integrate
> > that into a large software project I've been working on for years. I'd
> > definitely use JAX-RS so that we could keep the implementation entirely
> > within Java itself.
> >
> > But yes, I agree, having a RESTful API would obviate the need for XML-RPC.
> >
> > Cheers,
> >
> > Murray
> >
> > On 10/05/25 06:24, Juan Pablo Santos Rodríguez wrote:
> > > ouch I missed your email between all GH threads. I've also haven't
> > > seen xmlrpc usage of JSPWiki, but prefer to keep it there to see if we
> > > can keep it on 3.0.0 somehow, as we haven't any easy direct
> > > replacement. Perhaps a proper replacement would be to have a web API /
> > > some kind of JAX-RS, ideally derived from an openapi.yaml file.
> > >
> > > Also, if we finally ditch the xmlrpc support, it'd be matter of simply
> > > removing the module, the work of locating the affected code would be
> > > already done.
> > >
> > > cheers,
> > > juan pablo
> >
> > ...........................................................................
> > Murray Altheim <murray18 at altheim dot com> = = ===
> > http://www.altheim.com/murray/ === ===
> > = = ===
> > In the evening
> > The rice leaves in the garden
> > Rustle in the autumn wind
> > That blows through my reed hut.
> > -- Minamoto no Tsunenobu
> >
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Oh that be great!! top of my mind, the way we tackle this at work is
to specify an openapi.yaml file, and we derive the implementation from
that. Having the spec first has yield us a lot of benefits, but if you
feel like jumping directly on to the JAX-RS side, it'd be fine for me
too.
As per the API itself, I guess at least it should contain something
like login, logout and f.ex., crud for pages (crud for attachments,
admin, etc. could arrive later on). Everything except login should be
able to accept some kind of session/login id, be it a header or
whatever. Ideally, the code from the main jsp files should be
extracted so it can be reused on the REST api, so that both behave
equal and fixes can be done on only one place, but I don't know if
that's feasible.
If I'd be tackling that, all above would mean at least 3 new modules:
one for the openapi spec, another for the JAX-RS implementation and
the third one with the code extracted from the JSP files. But that
would me, approaching it, without having thought on it more than this
e-mail, so if you come with something different, it'd probably be fine
too.
WDYT?
cheers,
juan pablo
On Sat, May 10, 2025 at 4:48 AM Murray Altheim <mu...@altheim.com> wrote:
>
> Hi Juan Pablo,
>
> I know I haven't been very active for a long time in terms of contributing
> code (lots has happened at this end), but if I had a basic specification
> of what was expected I could probably build out a RESTful API for JSPWiki
> reasonably quickly (depending on whether or not there are any gotchas in
> the specification), and would be interested in doing so as it'd integrate
> that into a large software project I've been working on for years. I'd
> definitely use JAX-RS so that we could keep the implementation entirely
> within Java itself.
>
> But yes, I agree, having a RESTful API would obviate the need for XML-RPC.
>
> Cheers,
>
> Murray
>
> On 10/05/25 06:24, Juan Pablo Santos Rodríguez wrote:
> > ouch I missed your email between all GH threads. I've also haven't
> > seen xmlrpc usage of JSPWiki, but prefer to keep it there to see if we
> > can keep it on 3.0.0 somehow, as we haven't any easy direct
> > replacement. Perhaps a proper replacement would be to have a web API /
> > some kind of JAX-RS, ideally derived from an openapi.yaml file.
> >
> > Also, if we finally ditch the xmlrpc support, it'd be matter of simply
> > removing the module, the work of locating the affected code would be
> > already done.
> >
> > cheers,
> > juan pablo
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ === ===
> = = ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by Murray Altheim <mu...@altheim.com>.
Hi Juan Pablo,
I know I haven't been very active for a long time in terms of contributing
code (lots has happened at this end), but if I had a basic specification
of what was expected I could probably build out a RESTful API for JSPWiki
reasonably quickly (depending on whether or not there are any gotchas in
the specification), and would be interested in doing so as it'd integrate
that into a large software project I've been working on for years. I'd
definitely use JAX-RS so that we could keep the implementation entirely
within Java itself.
But yes, I agree, having a RESTful API would obviate the need for XML-RPC.
Cheers,
Murray
On 10/05/25 06:24, Juan Pablo Santos Rodríguez wrote:
> ouch I missed your email between all GH threads. I've also haven't
> seen xmlrpc usage of JSPWiki, but prefer to keep it there to see if we
> can keep it on 3.0.0 somehow, as we haven't any easy direct
> replacement. Perhaps a proper replacement would be to have a web API /
> some kind of JAX-RS, ideally derived from an openapi.yaml file.
>
> Also, if we finally ditch the xmlrpc support, it'd be matter of simply
> removing the module, the work of locating the affected code would be
> already done.
>
> cheers,
> juan pablo
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
ouch I missed your email between all GH threads. I've also haven't
seen xmlrpc usage of JSPWiki, but prefer to keep it there to see if we
can keep it on 3.0.0 somehow, as we haven't any easy direct
replacement. Perhaps a proper replacement would be to have a web API /
some kind of JAX-RS, ideally derived from an openapi.yaml file.
Also, if we finally ditch the xmlrpc support, it'd be matter of simply
removing the module, the work of locating the affected code would be
already done.
cheers,
juan pablo
On Thu, Apr 17, 2025 at 12:29 AM Murray Altheim <mu...@altheim.com> wrote:
>
> Hi,
>
> I've not seen XML-RPC used in software, even in legacy code that I've
> been hired to refactor, in many years. It would never, never be used
> in any new implementation, so I'm not even sure there's value in
> creating a separate support module for it. Does anyone have any
> evidence that it's being used by JSPWiki users anywhere?
>
> Cheers,
>
> Murray
>
> On 17/04/25 07:24, weberjn (via GitHub) wrote:
> >
> > weberjn opened a new pull request, #381:
> > URL: https://github.com/apache/jspwiki/pull/381
> >
> > Pulled out the xml-rpc code into a new submodule jspwiki-xmlrpc that is not linked to from the parent pom. So the problems with xml-rpc can be deferred to a later time. I doubt that nowadays anyone use xml-rpc.
> > Without xml-rpc all tests run and JSPWiki works on apache-tomcat-10.1.39 and wildfly-36.0.0.Final.
> >
> >
>
> --
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ === ===
> = = ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by Murray Altheim <mu...@altheim.com>.
Hi,
I've not seen XML-RPC used in software, even in legacy code that I've
been hired to refactor, in many years. It would never, never be used
in any new implementation, so I'm not even sure there's value in
creating a separate support module for it. Does anyone have any
evidence that it's being used by JSPWiki users anywhere?
Cheers,
Murray
On 17/04/25 07:24, weberjn (via GitHub) wrote:
>
> weberjn opened a new pull request, #381:
> URL: https://github.com/apache/jspwiki/pull/381
>
> Pulled out the xml-rpc code into a new submodule jspwiki-xmlrpc that is not linked to from the parent pom. So the problems with xml-rpc can be deferred to a later time. I doubt that nowadays anyone use xml-rpc.
> Without xml-rpc all tests run and JSPWiki works on apache-tomcat-10.1.39 and wildfly-36.0.0.Final.
>
>
--
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by "juanpablo-santos (via GitHub)" <gi...@apache.org>.
juanpablo-santos merged PR #381:
URL: https://github.com/apache/jspwiki/pull/381
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jspwiki.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by "weberjn (via GitHub)" <gi...@apache.org>.
weberjn commented on PR #381:
URL: https://github.com/apache/jspwiki/pull/381#issuecomment-2867659055
> Hi!, just a minor nitpick before merging, is `jspwiki-wikipages/de/.gitignore` really needed? maybe moving that entry to the project's `.gitignore` would be better? (not really sure why the bin folder is appearing, but happy to have it on the project's `.gitignore` file)
Of course.
Git blames me, but I cannot remember, so I do blame Eclipse.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jspwiki.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by "juanpablo-santos (via GitHub)" <gi...@apache.org>.
juanpablo-santos commented on PR #381:
URL: https://github.com/apache/jspwiki/pull/381#issuecomment-2867536537
Hi!, just a minor nitpick before merging, is `jspwiki-wikipages/de/.gitignore` really needed? maybe moving that entry to the project's `.gitignore` would be better? (not really sure why the bin folder is appearing, but happy to have it on the project's `.gitignore` file)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jspwiki.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Xmlrpc pull-out [jspwiki]
Posted by "weberjn (via GitHub)" <gi...@apache.org>.
weberjn commented on PR #381:
URL: https://github.com/apache/jspwiki/pull/381#issuecomment-2810566347
to make JSPWiki-jakarta run on current wildfly-36.0.0.Final:
add to the end of standalone.conf:
JAVA_OPTS="$JAVA_OPTS -Djspwiki.custom.config=/home/weberjn/jspwiki/jspwiki-custom.properties"
weberjn@dino:~/wildfly-36.0.0.Final/standalone/deployments$ unzip -d JSPWiki.war ~/gitrepos/jspwiki/jspwiki-war/target/JSPWiki.war
weberjn@dino:~/wildfly-36.0.0.Final/standalone/deployments$ touch JSPWiki.war.dodeploy
For container-managed security:
remove all
`<transport-guarantee>CONFIDENTIAL`
weberjn@dino:~/wildfly-36.0.0.Final/bin/add-user.sh
b) Application User
What groups .. : Authenticated
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@jspwiki.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org