On 5 Nov 2025, at 23:03, Ramsey Gurley<[email protected]> wrote:
WebObjects has this thing called NSBundle. And everyone is vaguely familiar
with it, because whenever your app isn't working, it's probably because of
NSBundle.
NSBundle is not actually a bad idea. It's an abstraction layer between your
application and the file system where your bundle resources are located. So
from the app's perspective, you just have to ask NSBundle for ClaimHome.wo, and
it finds it, or a localized version of it. You don't have to know the path is
actually Components/NonLocalized.lproj/ClaimHome.wo or whatever, it does that
part for you.
The problem is, you actually need to be able to extend the NSBundle yourself to
handle any type of new bundle layouts. Yet WebObjects went EOL in 2008.
NSBundle is written as some really crufty Java 1.5 spaghetti code... because
that's what was available when it was written. It supports a few bundle layouts
already. CFBundles, NSBundles, XCode projects, but conspicuously missing, is a
Maven bundle.
Mike Schrag and probably some others, modified NSBundle to work with maven
projects and added ERWebObjects and ERFoundation to project wonder to enable
that. It's essentially the same spaghetti code, but with a bundle factory
included where you can inject your own bundle handlers with properties. It's a
product of Apple, donated by Apple, no source code, no real license,
documentation, or anything. It's a little murky.
So around Jan/Feb of this year, with the goal of getting Project Wonder up onto
Maven central, I took it upon myself to rewrite NSBundle. It's current form is
on github under the erbundles project. It is completely rewritten using nice
things available since Java 8 like the java.nio.FileSystem. Which means,
there's no spaghetti code around whether your files are located in a folder
structure or in a jar. Using the java.util.ServiceLoader, it can load custom
NSBundle adaptors that you can produce yourself by implementing a single
interface. It has implementations for JarBundles, CFBundles, and in a separate
project which you can load conditionally with maven profiles, one that handles
Maven bundles. The Maven NSBundle just reads your pom.xml file to see where
you've located resources, and looks there. No special configuration involved.
It turns out that using java.nio.FileSystem was a good idea, because it should
also be able to read the new hotness which are Java Runtime images with a jrt:/
url too. I've already gotten it working with a new unreleased Jigsaw bundle
adaptor. I want to try to get a simple woapp running as a GraalVM native image
too, which, theoretically, it should be able to handle.
Back to the question about flattenComponents, I believe if you flatten, and you
have localized components, you're going to lose the localizations. I could be
wrong, but that's what it sounds like. The NSBundle you're probably using is
going to look in the jar under /Resources and /WebServerResources for stuff. If
you do have localization and you want to try it out, you could try making a
custom bundle adaptor for erbundles to handle your custom bundle layout in the
jar without flattening.
Ramsey
On 11/6/25 5:04 AM, Ricardo Parada via Webobjects-dev wrote:
Hello all,
I’m trying to figure out why some components render no html.
The component lives in the project folder under
Components/ClaimsProfessional/ClaimHome/ClaimHome.wo
Prior to maven conversion I can see the component is copied to a build folder,
something like this …/build/ClaimComponents.framework/Resources/ClaimHome.wo
And when I debug in Eclipse I see the WOComponentDefinition constructor gets
called with the path to that file.
In other words it seems like *all* components have been put together under
Resources folder after it builds the framework which is okay with me.
Now, when I build with maven and look inside the jar file for the framework
where the component resides I noticed that the components are not flattened.
The hierarchy of folders is preserved, e.g.
Resources/ClaimsProfessional/ClaimHome/ClaimHome.wo.
Anyways, I’m not sure if that is the reason why some components render no html
but my guess is that it is because otherwise WebObjects would have to do a
recursive search.
If anyone knows whether it is okay for maven to preserve the hierarchy of
folders under Components or whether it is supposed to copy all components and
put them together under Resources please let me know.
Thank you
Ricardo Parada
