Ulf Dittmer

+ Follow
since Mar 22, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ulf Dittmer

We've just released JForum 2.8.1, which contains a number of small fixes and improvements that we've made over the last 7 months.

  • Various font and background colors can be configured at runtime from the Configurations page. So if you ever disliked some particular color JForum used, chances are you can now change it without even the need of a restart.
  • More control over image attachments from the Configurations page
  • Optimize Recent Topics and Hot Topics for large installations. Large meaning at least 100.000 posts before it will make a difference.
  • Fixed an issue where the last visited time on the forum home page was not actually reflecting that, but the time of the last session start
  • Switch optional Google Analytics integration from analytics.js to gtag.js
  • Fixed a CSRF vulnerability
  • As always, many dependencies haven been updated to the latest versions.

  • A full list of new features is at https://sourceforge.net/p/jforum2/wiki2/NewFeatures281/, upgrade instructions are at https://sourceforge.net/p/jforum2/wiki2/UpgradingFrom280to281/ and you can download it from https://sourceforge.net/projects/jforum2/files/. The documentation is at https://sourceforge.net/p/jforum2/wiki2/Documentation/

    All feedback is welcome, preferably in our discussion forums.
    2 weeks ago
    It's been a while since the last release, and we've been busy adding features and fixing bugs to make JForum even better than it already is. Some of the new and improved features are:

  • Registration can be restricted to particular email addresses or email addresses from particular domains, and then be auto-assigned to specific groups.
  • The authenticity of outgoing emails can now be verified via DKIM.
  • The registration pages and the password recovery pages are now mobile-friendly.
  • It's now possible to log in with the email address as well as username, as that is what users expect these days.
  • New default connection pool, potentially increasing performance with multiple concurrent users.
  • Numerous bug fixes and small improvements

  • A full list of new features is at https://sourceforge.net/p/jforum2/wiki2/NewFeatures280/, upgrade instructions are at https://sourceforge.net/p/jforum2/wiki2/UpgradingFrom270to280/ and you can download it from https://sourceforge.net/projects/jforum2/files/. The documentation is at https://sourceforge.net/p/jforum2/wiki2/Documentation/

    All feedback is welcome.
    7 months ago
    Ah, I hadn't noticed that the original post was from 4 months ago. Nothing to see here then :-) Good luck with the sales!
    10 months ago
    Having read your earlier books (and having been an iText user for years), I'd be happy to review this one as well.
    10 months ago
    Why would that be different? A service may be used in different contexts, each requiring a different selection of data to be returned. Or it may be a multi-tiered application where, even though the ultimate client is a human being, the processing goes through a number of steps. That would be quite common in a microservice architecture.
    1 year ago
    That's a similar question to https://coderanch.com/t/740519/java/Graphql-usage-joining-multiple-tables. GraphQL is more a description language (i.e., which data a client wants) than a query language, and as such is not involved with the details of retrieving that data. That can be as complex or as simple as warranted.
    1 year ago
    GraphQL has nothing to do with databases. It describes which data the client wants, but it's up to the server to decide how best to store and retrieve it. Nothing changes in that respect - GraphQL is just another means of accessing the data.
    1 year ago
    Yes, that's possible, although it's not GraphQL's role to make this happen. GraphQL is used to describe which data the client needs - it's up to the server to retrieve that data, and return it to the client. So the client need not be aware whether the data comes from one or more tables, or whether it comes from a relational DB at all. So there's a decoupling, and the server-side data architecture could change fundamentally without the client ever becoming aware of it.
    1 year ago
    I found the OpenLIberty server quite easy to get started with, and it supports JEE as well as MicroProfile, including GraphQL. The easiest way to get started is this: https://github.com/OpenLiberty/sample-mp-graphql, discussed in https://www.openliberty.io/blog/2020/06/10/microprofile-graphql-open-liberty.html.

    The OpenLiberty blog has more information about various aspects of how to develop GraphQL application, like https://openliberty.io/blog/2020/06/05/graphql-open-liberty-20006.html and https://openliberty.io/blog/2020/08/28/graphql-apis-open-liberty-20009.html.
    1 year ago
    Thanks! The Apollo library seems to require a fixed query at compile time (except for parameters), which doesn't allow for much flexibility. But the Netflix library supports creating queries dynamically at runtime - which is the kind of flexibility that I think one wants when going to the effort of implementing GraphQL.
    1 year ago

    Lanny Gilbert wrote:How much more effort will it be to implement a GraphQL version of the server-side code vs. ReST? Or is the effort the same (more or less)?

    That's hard to say without seeing the actual REST API, but in most such APIs I've seen you do not have the capability to specify which parts of the data you want to get, exactly. You can usually specify things like a search term, or an ID for a specific data record, or a maximum number of items to fetch etc., but not select which data attributes, specifically, are returned. So the server-side code would not have the logic to deal with this. Which means that this question:

    Our clients, for the most part, want to do as little as possible in order to comply with the change from CORBA and/or SOAP to ReST or GraphQL.
         Given that these APIs have been around for 15-20 years, is it worth building GraphQL, with all its flexibility, instead of ReST, given that the clients will be sending and receiving the same data points, only in JSON format rather than wrapped up in CORBA or SOAP cruft?

    is really: does the client want to build in that kind of flexibility, now that the code needs to be substantially touched anyway? I'd say there's no general rule to decide either way, but if the APIs have been running for 15 years without changes as to what data is returned (or even 5 years), and there's no call for that kind of flexibility NOW, then it's probably safe to say that building this capability would be misguided at the moment.

    When building systems, it's always tempting to build in flexibility to accommodate future changes, but quite often the flexibility that's eventually required is different from the flexibility one envisions at the start (before the system is actually used). So in general, if the client is not asking for it, and you have no other reasons to suspect that it may be needed soon -which, obviously, you would discuss with the client- I'd say go without GraphQL.
    1 year ago
    I see that you're discussing Apollo in-depth as a client library, and are linking to a long list of client libraries in various languages. For a micro-service architecture one might have Java clients, not just browser or app. Can your recommend a particular Java client library or two that stand out from the crowd?
    1 year ago
    It's been a while since the last release, and we've been busy adding features and fixing bugs to make JForum even better than it already is. A servlet container that supports Servlet API 3.1 is now required, for example Tomcat 8. Some of the new and improved features are:

  • The Trash Can lets you designate one forum as trash can - meaning topics that get deleted are moved to it, rather than actually getting deleted from the database. If the forum is set up to be accessible by admins only, you keep deleted topics for future reference without them being publicly visible (which comes in handy on moderated forums frequently)
  • Banners can be shown on assorted pages, up to 3 at the top and up to 3 at the bottom, either as plain text or with HTML, including links. That could be used for announcements, or ads.
  • Added lots of missing translations to various languages
  • Many improvements for the mobile view: some pages were entirely missing before, and a new dropdown menu for navigation makes it easier to get around
  • Eight new smilies, some of them animated, like ROFL
  • Numerous bug fixes

  • A full list of new features is at https://sourceforge.net/p/jforum2/wiki2/NewFeatures270/, upgrade instructions are at https://sourceforge.net/p/jforum2/wiki2/UpgradingFrom25and26to270/ and you can download it from https://sourceforge.net/projects/jforum2/files/. The documentation is at https://sourceforge.net/p/jforum2/wiki2/Documentation/

    All feedback is welcome.
    2 years ago
    That's great, Stephan. The email was supposed to be in the image in the post, but apparently that only works for me. The email in my profile here is public - that's the right one.
    2 years ago
    As the JForum team prepares a new release, we want to improve a number of the localizations that have fallen behind. There are about 70 language entries that haven't been translated to Dutch yet, most of them fairly short. Is there anybody here interested in helping us out? If so, please get in touch with me via email.

    We could also use help for a number of other languages, namely Turkish, Japanese, Norwegian and Portuguese. Those are even further behind, so would need more work. But even a partial translation of the outstanding entries would be great.
    2 years ago