OK. I found a simpler approach than all that even. Using dom4j's
Rules, I can trigger actions based on xpath filters to create/fetch
objects as the Document is parsed. I don't need to worry about parsing
the xml or walking the object. I just register these Actions and let
dom4j trigger them as necessary. So as long as the dom4j dependency is
acceptable, we're in business.
Either way I'll need some guidance on matching up the xml elements to
the grizzly objects to build...
Now this doesn't address the glassfish->grizzly hand off but perhaps we
can simply get at the actual xml Document in glassfish and pass it down
to the grizzly config code...
Oleksiy Stashok wrote:
> Hi Justin,
>
>> I'm trying to figure out the best/easiest way to parse this config
>> and create the requisite object structures in memory. I'm trying to
>> balance simplicity and glassfish compatibility. It'd be nice to use
>> something like what glassfish uses (which seems to be hk2 based) but
>> that code is insanely complex and I'm not sure grizzly would really
>> gain that much from it. It *would* make it simpler for glassfish to
>> simply pass those objects off to grizzly config at runtime, though.
> Agree, it's probably too complex.
>
>> Another options is use SAX to just build them up as the document
>> streams by. Relatively simple but does require that we build up some
>> supporting code to manage xrefs between config components and the
>> like. We'd probably end up with a (hopefully) less complex system
>> than glassfish uses but might still end up a little convoluted.
> Agree. Clear SAX or StAX parsing will lead us to solving tasks, which
> have been solved already.
>
>> And there's also JAXB which would at least deal with parsing the XML
>> into an object structure we could walk through. This would still
>> need the same "back end" processing that a SAX based solution would
>> end up probably.
> +1 for JAXB. It is pretty easy to use it... May be you'll just need to
> tune the names in XML <-> Object mapping
>
>> What I'm trying to avoid is overengineering this thing to death but
>> still provide a fair bit of power and flexibility as configuration
>> elements come and go. It also needs to meld relatively painless into
>> glassfish's configuration routines as well. Any suggestions?
> I like JAXB.
> May be others have different opinion on that...
>
> Thanks.
>
> WBR,
> Alexey.
>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>