Dear Sahoo, Tom
About GLASSFISH-16998 and GLASSFISH-13006, I have a design idea
and want to discuss with you.
My design idea is as following:
1 "Turn off" org.apache.felix.shell.remote bundle
Just as Richard S. Hall said:
"From an OSGi perspective, the way to administratively turn off a bundle
is to stop it or not deploy it. "
I think that Stoping shell.remote bundle is a better way on the current
gf architecture.
Because on the current gf's code, GlassFishActivator class and
GlassFishActivator.startPostStartupBundles() have not been existed, I
think that the better way is to modify OSGiGlassFishRuntimeBuilder.build
method and add the logic to stop org.apache.felix.shell.remote bundle
behind "framework.start()" .
2 provide a way to administratively turn on shell.remote bundle
Just as said on GLASSFISH-13006, felix shell is also important not only
for framework developers(re-develop based gf), but also for OSGi app
developers.However, also need to consider people who are not interested
in OSGi. In addition, considering administrative and security aspects, I
think that:
Supporting a admin cli command for turning on shell.remote bundle,
liking the following:
asadmin start-felixremoteshell --telnet.port <portvalue> --portsavedfile
<filepath>
About design of the command,
1) --telnet.port is optional, if not inputing, gf will select an unused
port randomly.
2) after executing the command, gf will display the port value on
os-related shell window in order to let the user to know the port.
3) --portsavedfile is optional, if not inputing, gf will save the port
value on a file of "user.home" by means of enciphering the port value.
4) when executing the command again, if user does not input port value,
gf will firstly read port value from the portsavedfile, and if can't
get the port value from the portsavedfile, then, executing the logic of
1) and updating the portsavedfile.
--Best Regard!
--Tang