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
