Agreed with the JAXB bit. dom4j ended up not really saving me any work
on the back side and creates a little extra bit. and it makes it not
very glassfish friendly. So here's what i'm working toward now trying
to translate the xml elements to grizzly objects. Please correct me if
I'm wrong (and I wouldn't be surprised but so far it looks/feels correct).
For the <transport> elements, I'll create varying TCPSelectors based on
the attribute values (or their defaults) to handle setting up the HTTP/S
components and wire them up accordingly. What I'm a little nervous
about are the 1.9.0 changes. I'm not sure if the page i'm working from
(
http://is.gd/aHp2) is as up-to-date as we'd like it to be. But maybe
the leap from there to current best practice will be short.
Oleksiy Stashok wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>