> 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.
Yes, <transport> element should correspond to some SelectorHandler.
(TCPSelectorHandler by default).
HTTP/S part is protocol specific.
> 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.
1.9.0 has just thread pool API changes (no Pipelines anymore),
otherwise it doesn't have any API changes. So, I think sample could be
used without any problems.
WBR,
Alexey.
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>