Thanks Alexey.
Let us know if you want us to test any changes you make. I wouldn't be
surprised if we're using APIs that we're not supposed to.
FWIW, you guys have prompted me to "mavenize" our LDAP SDK as well. :-)
Matt
On 02/09/10 15:01, Oleksiy Stashok wrote:
> Hi Matt,
>
> thank you very much for the feedback.
>
>> I have a couple of feedback items for you:
>>
>> * Are you still planning to embed the gmbal stub library inside
>> Grizzly so that applications which use Grizzly don't need to go
>> and resolve the dependency themselves? An exception being of
>> course those applications which want to take advantage of the
>> JMX support in Grizzly.
>>
> For non-maven projects you would probably need to provide the gmbal
> binaries manually. Though we're planning to create bundle modules,
> similar to what we have for 1.9.x, which will bundle all the required
> classes out of the box.
>
>
>> * It's a big ask, but it would be really nice if your team could
>> spend some time going through the Grizzly sources and deciding
>> which APIs are public and which are not. There seem to be a
>> very large number of classes and methods which are probably not
>> intended for public consumption. It would be really nice verify
>> that they have the appropriate access rights (i.e.
>> public/package/protected/private) and update where necessary.
>> This would have two benefits: 1) user-friendliness since a
>> Grizzly with less classes and interfaces will be easier to
>> learn and navigate, and 2) compatibility since only public
>> classes/interfaces will need to remain stable.
>>
>> Of course this is not always possible to do - sometimes an
>> implementation class must be made public because another class
>> in a different package needs to access it. Something that we
>> have done in our LDAP SDK is to split the source tree in two
>> parts: a com.sun.opends.sdk.* package hierarchy containing
>> private implementation classes and a public org.opends.sdk.*
>> package hierarchy containing the public interfaces and classes.
>> Our Javadoc and src.zip only includes the public
>> org.opends.sdk.* package hierarchy, effectively hiding the
>> private package hierarchy. This is how they've managed the
>> problem for J2SE AFAIK.
>>
> Very good point. We've discussed this during our yesterday's meeting,
> and we will make a refactoring nearest time.
>
> Thanks again!
>
> WBR,
> Alexey.
>
>
>> * Presumably this kind of problem will be easier to solve when/if
>> JDK7 modules arrive. :-)
>>
>> Thanks again,
>>
>> Matt
>>
>> On 31/08/10 20:14, Oleksiy Stashok wrote:
>>> The Grizzly Team would like to announce the release of Grizzly 2.0
>>> RC1 (release candidate). This goal of this release was a stable
>>> core and solid API. While this is a significant step to getting
>>> Grizzly 2.0 finalized, we still have work to do in the area of
>>> documentation, performance, and resolving any feedback solicited by
>>> this release.
>>>
>>>
>>> The grizzly artifacts have been pushed to maven using the group ID
>>> *com.sun.grizzly* and versioned *2.0.0-RC1*.
>>> The following artifacts are available:
>>>
>>> * framework* (artifact ID: *grizzly-framework*) : The core
>>> Grizzly runtime.
>>>
>>> * http* (artifact ID: *grizzly-http*) : HTTP protocol
>>> implementation, which contains HTTP Filters and utility classes
>>> to work with
>>> HTTP artifacts.
>>>
>>> * webcontainer* (artifact ID: *grizzly-webcontainer*) :
>>> Lightweight Grizzly web server implementation, which provides high
>>> level
>>>
>>>
>>> abstractions based on the entities provided by the HTTP module.
>>> While the
>>>
>>> concept is similar to the Grizzly 1.x web server, it does expand
>>> this abstraction
>>>
>>> idea by providing an API for non-blocking streams to read/write
>>> application
>>>
>>> content.
>>>
>>> * websockets* (artifact ID: *grizzly-websockets*) : Web Sockets
>>> implementation based on *http* module.
>>>
>>> * framework-samples*, *http-samples*, *webcontainer-samples*,
>>> *websockets-samples*: modules, which demonstrate
>>> functionality of the Grizzly 2.0 modules
>>> described above.
>>>
>>>
>>> Here are links to the basic Grizzly 2.0 samples and blogs:
>>>
>>> - TCP echo sample [1]
>>> - UDP echo sample [2]
>>> - SSL sample [3]
>>> - Tunnel server [4]
>>> - HTTP sample [5]
>>> - JMX support [6]
>>> - Web container blocking I/O sample [7]
>>> - Web container NIO streams sample [8]
>>> - Web sockets blog [9]
>>> - Web sockets chat sample [10]
>>>
>>> and more blogs and documentation to come...
>>>
>>> We will really appreciate community feedback!
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>>
>>> [1]
>>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/framework-samples/src/main/java/com/sun/grizzly/samples/echo/
>>> [2]
>>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/framework-samples/src/main/java/com/sun/grizzly/samples/udpecho/
>>> [3]
>>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/framework-samples/src/main/java/com/sun/grizzly/samples/ssl/
>>> [4]
>>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/framework-samples/src/main/java/com/sun/grizzly/samples/tunnel/
>>> [5] http://blogs.sun.com/oleksiys/entry/grizzly_2_0_asynchronous_http
>>> [6] http://blogs.sun.com/rlubke/entry/grizzly_2_0_now_has
>>> [7]
>>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/webcontainer-samples/src/main/java/com/sun/grizzly/samples/webcontainer/blockingadapter/
>>>
>>> [8]
>>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/webcontainer-samples/src/main/java/com/sun/grizzly/samples/webcontainer/nonblockingadapter/
>>> [9] http://blogs.sun.com/oleksiys/entry/grizzly_2_0_websockets_support
>>> [10]
>>> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/websockets/chat/
>