Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty 9 + Websocket Modules

I think we are planning on teasing out a smaller artifact intended to
go into web-inf/lib which should follow that naming convention

the others are already websocket and I dislike the idea of renaming
them as it shifts things around in maven central artifact locations
and leads to a confusing mess there :/

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Thu, Nov 8, 2012 at 4:30 PM, Eirik Bjørsnøs <eirbjo@xxxxxxxxx> wrote:
>
> How about we add "jetty-" as an artifact prefix on the
> org.eclipse.jetty.websocket artfacts?
>
> Right now, they end up in WEB-INF/lib as websocket-*-9.0.0.M2.jar, which is
> kind of secretive.
>
> I think most, if not all other Jetty artifacts have "jetty-" as a file name
> prefix.
>
> Thanks,
> Eirik.
>
> On Thu, Nov 1, 2012 at 6:56 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
>>
>> There's been a few filed issues around the websocket modules that I'd like
>> to get resolved.
>> Mostly it has to do with using websockets from a webapp, with the
>> classloader in play.
>>
>> This root cause seems to be the use of Callback and FutureCallback in the
>> exposed API itself.
>> This will need to change, i'm already investigating just moving to a pure
>> Future approach with the exposed API.
>>
>> There is also the new JSR-356 (Currently in the Early Draft 006) that
>> needs to be implemented and made available for webapps to use.
>>
>> So that leads me to believe we should take advantage of the fact that we
>> are in the Milestone releases to make the hard decisions on
>> packaging/modules now, before we hit 9.0.0 final release.
>>
>> So here's my plan, I'd appreciate anyone picking apart this plan (so I can
>> shore up the faults in it)
>>
>> First step: the proposed module layout
>> Rationale: To break apart what goes in the webapp's WEB-INF/lib and
>> simplify what we let peek through the WebAppClassloader from the server
>> side.
>>
>> /websocket-api/
>>   org.eclipse.jetty.websocket.api.*
>>   Holds the Jetty implemented WebSocket API that can be used to create
>> either Client or Server side WebSockets.
>>   This would be a package exposed on WebAppContext's systemClasses.
>>   This MUST NOT depend on the servlet-api.
>>   This would not depend on any other module within jetty.
>>
>> /websocket-servlet/
>>   org.eclipse.jetty.websocket.servlet.*
>>   This is the servlet specific classes for using WebSockets in a standard
>> webapp.
>>   For developers wanting to use the jetty api in their webapps, this is
>> the dependency they would use for their webapp's WEB-INF/lib.
>>   It would depend on websocket-api.
>>   This would be a package exposed on WebAppContext's systemClasses.
>>   This MUST depend on the servlet-api.
>>
>> /websocket-client/
>>   org.eclipse.jetty.websocket.client.*
>>   For those wanting to implement a WebSocket client in their java
>> application, this is what we recommend you depend on.
>>   This MUST NOT depend on the servlet-api.
>>
>> /javax-websocket-api/
>>   javax.net.websocket.*
>>   This is already exposed on WebAppContext's systemClasses via the "javax"
>> namespace.
>>   This MUST depend on the servlet-api
>>
>> /websocket-server/
>>  org.eclipse.jetty.websocket.server.*
>>   Holds the jetty server side specific components, along with the server
>> specific implementation details for JSR-356 (aka /javax-websocket-api/).
>>   So far, there seems to be no client component for JSR-356, so there will
>> likely be no reason to put the implementation of JSR-356 into any other
>> component (of course, this might change as the JSR isn't done yet)
>>   This MUST depend on the servlet-api
>>
>> /websocket-common/
>>   org.eclipse.jetty.websocket.common.*
>>   Holds common classes for /websocket-client/ and /websocket-server/,
>> these classes shouldn't be exposed to the webapp, as they are really just
>> server side implementation details.
>>   This MUST NOT depend on the servlet-api.
>>   All of the protocol, I/O, and extension handling is done here.
>>
>>
>> Next, we remove from /websocket-api/ and /websocket-servlet/ any exposed
>> use of org.eclipse.jetty.* classes.  (such as Callback and Log)
>>
>> Hopefully this made sense.
>>
>> --
>> Joakim Erdfelt <joakim@xxxxxxxxxxx>
>> webtide.com
>> Developer advice, services and support
>> from the Jetty & CometD experts
>> eclipse.org/jetty - cometd.org
>>
>>
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>


Back to the top