Hi Justin,
> 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.
it's fine, though I have certain concerns (bellow)...
> Either way I'll need some guidance on matching up the xml elements
> to the grizzly objects to build...
Ok, no problem. If you have any concrete question - I'll be glad to
help with mapping.
> 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...
Yep, and this is concern. Not sure hk2 will pass us configuration as
XML :( They'll pass config with objects.
In this case I think JAXB could be better...
In Grizzly framework you can define general configuration objects
interfaces like:
public interface Transport {
public String getId();
public String getClass();
..................
}
public interface Protocol {
public String getId();
public String getClass();
..................
}
Then you'll generate JAXB objects, which will implement that common
interfaces.
In GFv3 code base, we can generate hk2 config classes, which will also
implement general Grizzly config interfaces.
So the standalone Grizzly implementation and GFv3 integration could be
done similar way.
What do you think?
Thanks.
WBR,
Alexey.
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>