You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Rob Walker <ro...@ascert.com> on 2008/06/23 15:13:02 UTC
Re: telnetd and embedded felix
Craig
Glad you've had some use out of telnetd bundle - it was just a very
quick hack we did a while back to get us out of a "hole", and it's not
something we've used much of-late.
I'm not sure where this is happening - but I'm pretty sure I know what
is happening.
At startup - the telnetd code will almost certainly be following normal
TCP/IP coding and will create a listener socket, and then accept
incoming connections by on new additional sockets. At close down - I'd
bet that there's no call to disconnect / shutdown the listener socket,
meaning when you try and start up again the port is in use.
One thing that's a little confusing is that your port is still showing
LISTENING - this implies to the OSGi java process itself is not actually
exiting. Usually when a process exits without a clean TCP/IP
close/shutdown, the port will get left something like FIN_WAIT /
TIME_WAIT or CLOSE_WAIT state. I'm 90% sure that there's no way the
socket would be left listening if the process had actually exited, so
I'd be tempted to do a "ps" or Task Manager depending on your platform
to see if you have any zombie java or javaw processes lying around.
Now ... if you do find there is a java zombie lying around, it's
probably a further effect of needing an active "close" of the telnetd
listener. What I'd guess is happening is that the process is set to not
exit whilst daemon threads are lying around, and the since the
"listen()" call has suspended the thread, it's blocked and also
preventing an exit.
The answer here is almost certainly to trap the bundle stop() event
and/or framework shutdown() and call into telnetd to ask to disconnect /
close / shutdown.
I'm afraid at this point I'd need to leave you to investigate further -
at least for now (I'm stuck on a GWT problem at present!) - but
hopefully there's a simple telnetd API call to close down you can try
adding in.
Regards
-- Rob
Craig Phillips wrote:
> Rob,
>
> Sorry to trouble you, but you might know off the cuff...
>
> I'm trying to do embedded OSGi... At first, I tried equinox, but it
> has a somewhat fatalistic bug (I logged a "DR" with bugzilla), along
> with some quirks due to static methods in the starter... So, I moved
> to felix.. One note -- I have 'felix.embedded.execution' set to true;
>
> BTW, I have had great mileage from telnetd...
>
> With that said, there's a riddle with embedded felix and the telnetd
> port, for which I suspect you already have a inkling about... When I
> do a shutdown of the OSGi container (in several of various ways), the
> telnetd listen port (6623) is still in an active listening state, as
> shown below a la 'netstat -a':
>
> $ netstat -a | grep 6623
> TCP MyHostName:6623 MyHostName:0 LISTENING
>
> I replaced the actual host name with 'MyHostName'... not that I'm all
> that paranoid, but just sort of out of protective habit, more or less...
>
> When I start up a new OSGi container, the telnetd cannot bind to port
> 6623 because it's already in use...
>
> I figure, you probably can give me the "low down" / insight into the
> story and save me some time/effort... Otherwise, I guess I'll be
> digging deeper... I have the source for telnetd (thanks), but not for
> the dtw.jar file (I guess there's probably some source out there for
> this if I poked around, presumably)...
>
> Appreciate any feedback you can provide and sorry to trouble you,
> thanks again, Craig Phillips, Praxis
>
> ------------------------------------------------------------------------
> *From:* Rob Walker
> *Sent:* Tue 5/13/2008 10:13 AM
> *To:* Craig Phillips
> *Cc:* users@felix.apache.org
> *Subject:* Re: how to specify telnetd port?
>
> No worries Craig - just a general point, it's usually best to email
> the Felix users or dev list (I pick up these lists also - so will
> generally respond if around and able to).
>
> I seem to recall this bundle being a very very quick hack - and as
> such, I don't think there's an actual property exposed in OSGi config
> that controls this.
>
> What it does is use the original underlying TelnetD properties files -
> and lookign at the code, I believe the port was specified in
> resource/Listener.properties:
>
> this.listenerProps =
> PropertiesLoader.loadProperties(this.getClass().getResource("resource/Listener.properties"));
>
>
> Would be fairly trivial to expose an override to this property - or
> else just hack this file within the JAR
>
> BTW - my email has changed, new email is as per this message
>
> Regards
>
> -- Rob
>
> Craig Phillips wrote:
>> Hi Rob,
>>
>> Sorry to bother you... My name is Craig Phillips, praxis
>> engineering... I'm using felix and find the telnetd service very
>> useful... however, I can't seem to find documentation on how to set
>> the port... I suspect there is a config.properties entry?
>>
>> Thanks and sorry to trouble you, Craig
>>
>
> --
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> http://www.ascert.com/
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: GWT
Posted by Rob Walker <ro...@ascert.com>.
Marcel
> ...just wondering, are you actually using GWT in an OSGi context (to
> build a UI out of components)? I have a customer that wants to look
> into that so I was wondering if you have any experiences you might
> want to share here.
Yes we are - using Felix, and the normal Felix Http bundle. We're still
on the old jetty4 based one from a couple of revs back. It works very
well too.
Pretty standard model:
* we create a single "ui" bundle - which contains:
o the gwt-user.jar as an embedded jar
o the gwext.jar (we were using mygwt and gxt, but there's been
a license brew-ha-ha which has steered us away from this).
o the java compiled outputs
o the compiled output of the GWT compiler i.e. the "www" root
o our GwtServlet which serves up the JS, HTML etc. resources
o our Rpc server classes - which are lightweight layers that
wire themselves into our core service classes elsewhere in
the OSGi instance
* we still use my old mangen approach for manifests (have attached
an example below)
* we use service binder for our service wiring (also attached our
I think when we first started we had the usual "trace and analyse" what
HTTP resource requests we were getting, and how to resolve them in our
GwtServlet class. But it didn't prove too hard:
We mount our app at:
http:://localhost:8084/VtWebUi
Our "app entry point"
protected String baseUri = "/com.ascert.webui.vt.VtWebUi";
This matches what's in your GWT XML and HTML
<entry-point class="com.ascert.webui.vt.client.VtWebUi" />
<script type="text/javascript"
src="com.ascert.webui.vt.VtWebUi.nocache.js"></script>
In our servlet, we use the following properties:
public GwtServlet(ServiceBinderContext context)
{
this.context = context;
alias = getProperty("webui.uri", "/VtWebUi");
resourceFsBase =
context.getBundleContext().getProperty("webui.fs.resource.base");
...
I'll cover what resourceFsBase does in a moment
We mount the following aliases for RPC services and too resolve
resources
public void activate()
{
try
{
srvHttp.registerServlet(alias +
"/EnvironmentService", this.envSvc, new Hashtable(),
myContext);
srvHttp.registerServlet(alias + "/ClientService",
this.cliSvc, new Hashtable(), myContext);
srvHttp.registerResources(alias, "", myContext);
...
And then to resolve resources in our myContext instance
private class WebUiContext implements HttpContext
{
public URL getResource(String name)
{
if (name.equals("/"))
{
name = "/VtWebUi.html";
}
diag.debug("getResource: " + name);
URL retVal = null;
try
{
//allowing FS overriding useful for testing.
if (resourceFsBase != null && new
File(resourceFsBase + name).exists())
{
retVal = new URL("file:" + resourceFsBase +
name);
}
if (retVal == null)
{
retVal =
GwtServlet.class.getClassLoader().getResource("resources/www" +
baseUri + name);
}
In a normal running case resources are server from the
GwtServlet class loader by the last case. But resourceFsBase
let's us do a pre-emptive check and serve direct from the
filesystem. This is very handy for tweaking CSS layouts, since
it lets you change CSS resources and try how the look without a
recompile.
Think that's the essence of the wiring - the rest is pretty much vanilla
OSGi and GWT
Here's those other attachments
_bundle manifest:
_
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Bundle-ClassPath: .,gwt-user.jar,gwtext.jar
Metadata-Location: metadata.xml
Bundle-Name: VtWebUI
Bundle-ManifestVersion: 2
Created-By: 1.6.0_03-b05 (Sun Microsystems Inc.)
Bundle-Activator: com.ascert.webui.vt.ServiceActivator
Bundle-Description: WebUI for VersaTest
Import-Package: com.ascert.tas.api, com.ascert.vt.testcase, javax.imag
eio, javax.servlet, javax.servlet.http, javax.xml.parsers, org.apache
.felix.servicebinder, org.apache.log4j, org.osgi.framework, org.osgi.
service.http, org.w3c.dom
Bundle-SymbolicName: com.ascert.webui.vt
Name: com/ascert/openosgi/mangen
Import-Package: org.osgi.service.http
mangen-rule-0: Ignore imports(org.springframework.*,junit.*,com.google
.gwt.core.ext.*,com.google.gwt.dev.*,com.google.gwt.util.tools,org.ap
ache.tapestry.util.text,org.eclipse.jdt.*)
mangen-rule-1: Ignore exports(javax.servlet,javax.servlet.http)
_sb metadata:_
<?xml version="1.0" encoding="UTF-8"?>
<bundle>
<instance class="com.ascert.webui.vt.GwtServlet">
<requires
service="org.osgi.service.http.HttpService"
filter=""
cardinality="1..1"
policy="dynamic"
bind-method="bindHttp"
unbind-method="unbindHttp"
/>
<requires
service="com.ascert.tas.api.TestRunnerService"
filter=""
cardinality="1..1"
policy="dynamic"
bind-method="bindTestRunner"
unbind-method="unbindTestRunner"
/>
</instance>
</bundle>
Good luck
-- Rob
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com