Hi All, Since there are quite some Jamon code, as a first step I created a PR to migrate the Master Status page back to JSP: https://github.com/apache/hbase/pull/6875
I still have to test it a bit more but I'd be interested in your opinion about it. Many thanks, Dávid Dávid Paksy <paksyda...@gmail.com> ezt írta (időpont: 2025. márc. 27., Cs, 11:49): > Many thanks for your responses and for the good discussion. > > For the next step, I created HBASE-29223 to start migrating Jamon back to > JSP. > > Best Regards, > Dávid > > Nick Dimiduk <ndimi...@apache.org> ezt írta (időpont: 2025. jan. 22., > Sze, 14:05): > >> On Wed, Jan 22, 2025 at 8:04 AM Istvan Toth <st...@cloudera.com.invalid> >> wrote: >> > >> > On the beans topic: >> > It does not have to be RPC, for server-side rendered pages, simply >> > moving non-trivial logic from the JSP file itself to a separate java >> class >> > may be an improvement. >> > (Though most of the heavy lifting is already done via the HBase API) >> >> This is the type of improvement that I meant to suggest when bringing >> up Jersey and beans. My thinking is that we would render out all the >> information necessary to present a page as a self-contained "bean" / >> POJO / whatever data object, and then the UI would be responsible only >> for rendering an appropriate view of that object. The existing Jersey >> stuff renders to JSON, but we can just as easily render to html. >> >> I think that we are aligned on principal. >> >> Thanks, >> Nick >> >> > On Thu, Dec 12, 2024 at 1:20 PM Nick Dimiduk <ndimi...@apache.org> >> wrote: >> > >> > > Thanks for bringing this up Dávid. >> > > >> > > Istvan has covered a lot of ground in his reply and I generally agree >> with >> > > him. I agree that we should support server-side rendering over a >> JS-heavy >> > > solution. I agree that JSP is old but an entrenched standard, which >> has >> > > some appeal given our history. >> > > >> > > I am concerned that we won’t ever attract frontend developers by >> leaning >> > > into such an old technology stack. This hurts the project doubly >> because it >> > > means both our product AND our website languishes looking old and >> outdated. >> > > >> > > I think that we should be able to selectively opt-in to more modern JS >> > > features. The Region Visualizer on the Master UI is one such example. >> To be >> > > my own critic on that feature, I do not know if the UI degrades >> gracefully >> > > for a client that does not support JS. >> > > >> > > On the comment about moving the JSPs over to consuming beans, I did >> start >> > > an effort around this by introducing a modern (at the time) Jersey >> > > environment. I think anyway that we can continue to build on Jersey to >> > > render model objects that get rendered out via JSP (or whatever). >> > > >> > > Thanks, >> > > Nick >> > > >> > > On Thu, 12 Dec 2024 at 12:55, Istvan Toth <st...@cloudera.com.invalid >> > >> > > wrote: >> > > >> > > > I never thought that I would voice support for JSP, but I think >> that the >> > > > Jamon situation is a good example of the advantages of JSP. >> > > > >> > > > Yes, JSP is old, kludgy and limited, but it has been around since >> > > forever, >> > > > and as it is part of the Java EE (jakarta) standard, we can also >> expect >> > > it >> > > > to be around for a long time. >> > > > Jamon was a hot new thing when it was adopted by us, but just two >> years >> > > > later it was discontinued. >> > > > >> > > > I think that given what the HBase web UI needs to do, and given the >> lack >> > > of >> > > > frontend focus and resources in HBase, something like JSP is >> exactly the >> > > > right technology for us. >> > > > It is simple, super easy to pick up, has minimal dependencies, and >> there >> > > is >> > > > a minimal surface area for security issues with it. >> > > > >> > > > If we move to another server-side rendering framework, there is no >> > > > guarantee that that framework would be around long enough for our >> > > purposes. >> > > > >> > > > (Having said that, the existing JSP pages could certainly be >> improved by >> > > > moving most of the Java code to some backing beans) >> > > > >> > > > I also want to pre-emptively mention that I would consider moving >> to some >> > > > client-side rendering framework a huge mistake, as HBase does not >> need >> > > such >> > > > functionality, and adding another intense upgrade and rewrite >> treadmill >> > > > that few of us has the expertise for would just waste our resources. >> > > > >> > > > Istvan >> > > > >> > > > On Thu, Dec 12, 2024 at 11:30 AM 张铎(Duo Zhang) < >> palomino...@gmail.com> >> > > > wrote: >> > > > >> > > > > Are there any new ways to implement this? >> > > > > JSP is also a very old technology... >> > > > > >> > > > > Dávid Paksy <paksyda...@gmail.com> 于2024年12月12日周四 17:58写道： >> > > > > > >> > > > > > Hi, >> > > > > > >> > > > > > Sorry for sending this again - but the former mail landed in >> spam >> > > > > (because >> > > > > > of the links) for some people. >> > > > > > >> > > > > > While I was working on HBASE-28832 to migrate Bootstrap I >> noticed >> > > that >> > > > > > HBase have a mix of JSP and Jamon code. Looks like HBASE-3835 >> started >> > > > the >> > > > > > work in 2011 of converting from JSP to Jamon, but the work >> didn't >> > > > finish. >> > > > > > I guess the best would be to either migrate everything to Jamon >> or >> > > back >> > > > > to >> > > > > > JSP as having both is not ideal from maintenance perspective. >> > > > > > >> > > > > > While Jamon has advantages (static typing of template >> arguments, unit >> > > > > > testing, etc), looking at the Jamon project, it seems that the >> last >> > > > > release >> > > > > > was on 2013-12-29 and I see no newer activity. >> > > > > > >> > > > > > From this I think moving back the Jamon files to JSP would >> maybe make >> > > > > more >> > > > > > sense now. >> > > > > > >> > > > > > What do you all think about this? >> > > > > > >> > > > > > Many thanks in advance, >> > > > > > Dávid >> > > > > >> > > > >> > > > >> > > > -- >> > > > *István Tóth* | Sr. Staff Software Engineer >> > > > *Email*: st...@cloudera.com >> > > > cloudera.com <https://www.cloudera.com> >> > > > [image: Cloudera] <https://www.cloudera.com/> >> > > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: >> > > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> > > Cloudera >> > > > on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > > > ------------------------------ >> > > > ------------------------------ >> > > > >> > > >> > >> > >> > -- >> > *István Tóth* | Sr. Staff Software Engineer >> > *Email*: st...@cloudera.com >> > cloudera.com <https://www.cloudera.com> >> > [image: Cloudera] <https://www.cloudera.com/> >> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: >> > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: >> Cloudera >> > on LinkedIn] <https://www.linkedin.com/company/cloudera> >> > ------------------------------ >> > ------------------------------ >> >
