[JBoss AS Development] - Re: Naming over Remoting 3
by ron.sigal＠jboss.com
Update.
I've got a version of Naming running over Remoting 3.
On the server side, there's an org.jnp.server.remoting.NamingServerRequestListener, an invocation handler, that just wraps an instance of org.jnp.server.NamingServer.
On the client side, there's an org.jnp.interfaces.remoting.NamingProxyFactory, which creates a Remoting 3 client connected to a Remoting 3 server and returns a proxy that wraps the client and implements org.jnp.interfaces.Naming. org.jnp.interfaces.NamingContext.getServer() then calls NamingProxyFactory.getNamingProxy() instead of the current bootstrap process. Everything else stays the same.
Right now the Remoting 3 client is sending its requests in instances of org.jboss.invocation.MarshalledInvocation, since invokablecontainer was complaining that my version of maven was too new, but I guess it wouldn't be too hard to replace MarshalledInvocation with invokablecontainer's version.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267138#4267138
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267138
16 years, 4 months
[JBoss Remoting Development] - Re: Remoting 3 protocol SPI
by david.lloyd＠jboss.com
When creating an endpoint via Remoting.createEndpoint(), all the protocol transports that exist on the classpath will be automatically installed into the endpoint. When creating an endpoint via AS, the deployer system will be used instead, but the results are the same - the protocols are installed automatically.
So essentially, if you remove the second and third lines from your first example, it should just work, as long as the protocol exists on the classpath.
You can still install additional protocols manually via Endpoint.addConnectionProvider().
I do want a better solution for servers though. Problem is, there's really no truly generic representation for servers. You can't just throw a SocketAddress and an OptionMap at it, because (a) it might not even involve a socket, and (b) you may need more information that can't be specified by an OptionMap (such as the Executor in your example). Right now, if you are the one who registers the connection provider, you can use the return value from that method to get an interface to control the server, though the interface type is specific to the ConnectionProviderFactory. But if not (e.g. if the provider was detected), you're S.O.L. Perhaps a method on Endpoint like this could solve the problem:
T getProviderInterface(String uriScheme, Class<T> interfaceType)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267137#4267137
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267137
16 years, 4 months
[JBoss Remoting Development] - Remoting 3 protocol SPI
by ron.sigal＠jboss.com
Some discussion about protocol independent proxies in the thread "Naming over Remoting 3" in the JBoss AS Development forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266845#4266845) has suggested to me the following idea. I'd like to be able to do something like
| ...
| Endpoint clientEndpoint = Remoting.createEndpoint("clientEndpoint");
| Protocol protocol = Remoting.getProtocol(url.getProtocol());
| protocol.registerClientTransport(clientEndpoint, clientExecutor, "localhost");
| Connection connection = clientEndpoint.connect(url), OptionMap.EMPTY).get();
| Client<String, String> client = connection.openClient("servicetype", "group", String.class, String.class).get();
|
The idea is that
1. the protocol class hides the details involved in endowing an endpoint with the ability to communicate over a particular protocol, and
2. making the protocol class accessible this way would facilitate protocol neutral code.
The org.jboss.remoting3.samples.socket.SocketProtocol class, for example, which is based on a similar class from an earlier sample protocol, looks more or less like this:
| public class SocketProtocol {
|
| /**
| * Register ConnectionProvider.
| * This endpoint can be a socket transport client.
| */
| static public <T, I, O> void registerClientTransport(final Endpoint endpoint, final Executor executor, final String host) {
| ...
| }
|
| /**
| * Register ConnectionProvider and start its listening facility.
| * This endpoint can be both a client and server for the socket transport.
| */
| static public <T, I, O> Cancellable registerServerTransport(Endpoint endpoint, Executor executor, final String host, final int port) {
| ...
| }
|
| /**
| * Register a service with an endpoint.
| * This endpoint must be acting as a socket transport server.
| */
| static public <I, O> void startService(Endpoint endpoint, Executor executor, SocketServiceConfiguration<I, O> socketConfig, final RequestListener<I, O> requestListener) throws IOException; {
| ...
| }
| }
|
So, I'm suggesting abstracting that to an interface.
WDYT?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267127#4267127
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267127
16 years, 4 months
[JBoss AS Development] - Graceful Shutdown
by ALRubinger
@see https://jira.jboss.org/jira/browse/JBBOOT-116
The objective discussed at the AS Design Meeting was to allow for all current requests and sessions to continue operating as expected while disallowing new ones. Only after a subsystem has completed all of its pending work may it be brought out of service.
Initially we'd tossed around the idea of a registration API alongside jboss-bootstrap which would allow components to opt-in to receive a 2-phase event, and handle accordingly. But this doesn't handle dependencies between subsystems:
Web request > Servlet > SLSB > JCA > MDB
This means that web must stop accepting requests before EJB3 does, else the request will break during the invocation. For this Brian, Jesper and I have discussed leveraging the MC dependency chain to do this a bit more intelligently.
The solution on the table is to add a "pre-stop" phase. Subsystems may handle @PreStop lifecycle events, and MC will guarantee that these are fired in order (assuming the dependencies are explicitly and correctly declared between components).
So for instance:
@PreStop
| public void gracefulShutdownPrepare(){
| // Shut down listener for new requests
| listener.stop();
|
| // Block until all current sessions have ended or are expired
| while(hasCurrentSessions()){
| Thread.sleep(1000);
| }
|
| // OK, go on to the next dep in the chain
| return;
| }
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267115#4267115
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267115
16 years, 4 months
[JBoss OSGi Development] - Remaining resolver issues
by thomas.diesler＠jboss.com
Folks,
I have now removed the dependencies on the Resolver API and use PackageAdmin instead. Have a look at AbstractImportExportTest. There are currently three variations of this test case.
* BasicResolver
* RuleBasedResolver
* NoExternalResolver
The goal would be to remove all external resolver implementations and have none installed in the MC Framework. This however is currently not possible because of some non-trivial issues that are fixed by the Resolver approach.
The most important one is covered by
https://jira.jboss.org/jira/browse/JBOSGI-151
Consider
| BundleC
| exports A, B
| imports A
|
| BundleD
| exports A,
| imports A, B
|
This only resolves when BundleC resolves using a self import for package A.
If the MC resolver could actually reason over the full set of installed modules, the choice where it gets package A from would be arbitrary. Currently it however works such that it irrevocably uses the first match and cannot try another attempt if resolution is not sucessful.
| Tests in error:
| testCircularInstallDbeforeC(org.jboss.test.osgi.jbosgi151.OSGI151TestCase)
|
The following list defines the preferences, if multiple choices are possible,
in order of decreasing priority:
⢠A resolved exporter must be preferred over an unresolved exporter.
⢠An exporter with a higher version is preferred over an exporter with a lower version.
⢠An exporter with a lower bundle ID is preferred over a bundle with a higher ID.
There is test coverage for this, which also fails with NoExternalResolver.
A related issue is this code in PackageAdminImpl
| int resolved = 1;
| while (resolved > 0)
| {
| resolved = 0;
| Iterator<OSGiBundleState> it = resolvableBundles.iterator();
| while (it.hasNext())
| {
| OSGiBundleState bundleState = it.next();
| if (bundleManager.resolveBundle(bundleState, false))
| {
| it.remove();
| resolved++;
| }
| }
| }
|
It iteratively tries to resolve the bundles through the MainDeployer by moving them to stage CLASSLOADER one by one. What's missing is an API that allows PackageAdmin to resolve the given bundles all at once.
https://jira.jboss.org/jira/browse/JBDEPLOY-226
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267110#4267110
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267110
16 years, 4 months
[JBoss Tools Development] - Re: [Struts Flow Editor Bug] any solution or advise for debu
by max.andersen＠jboss.com
"keibun" wrote : Thanks scabanovich!
| I'm surprised at your quick response and clear explanation.
| my team heavily use struts flow editor. I owe you very much, thank you!
|
| I want to contribute to development as much as posible,
| I'm very new to jboss community, so would you tell me
| some manner at the community?
|
I can try. Note, we don't do much on the struts tooling beyond major bugs fixing so we are looking for contributors wanting to help make them better ;)
anonymous wrote :
| 1. When finding problem which is better ?
| a. reporting to "develper forum"
| b. creating issue on JIRA.
|
if you are not sure it is a bug, post to the forum and then if its recognized as a bug you will be asked to post the details in jira.
if sure it is a bug, go to jira.
anonymous wrote :
| 2. Is there any good develor tutorial for develper who want to
| send patch or participating develpment process.
| I'm also interested where most core jboss developer gathers, e.g mailing list or forums.
|
jboss.org/tools got all the details - I don't have a specific one for jboss tools development, but I really should make one.
anonymous wrote :
| 3. Should I do something agains bug which I reported?
| Will this bug be fixed by someone and when?
| I'm not sure I can fix this bug quickly so I want to know
| how reported bug are treated in general.
|
We try and look at them all, but we might miss some. If you got a fix for a bug then please do not hesitate to say that and attach a patch.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267076#4267076
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267076
16 years, 4 months
[JBoss AS Development] - Re: Naming over Remoting 3
by bstansberry＠jboss.com
"david.lloyd(a)jboss.com" wrote : "wolfc" wrote : The most important bit herein is that the proxy itself should not contain any transport information. Whatever we put into JNDI is not fully aware of the network topology. Take for example a NAT firewall. In that case only the client knows how to communicate to AS. Although we could inform the server somehow, it is really outside of its scope.
|
| The proxy would have to know some transport information. If it does not, there is no way for the client (or whoever reads the proxy from JNDI) to know where it's connecting back to, or how.
For a cluster it's more tricky. The client might know how it connected to the JNDI server but it won't have any idea how to connect to the other nodes in the cluster.
"david.lloyd(a)jboss.com" wrote : However, I don't see any sensible way we can get around having separate proxy implementations for IIOP/JRMP/Remoting/whatever.
Are we finally going to get rid of JRMPInvoker in AS 6?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267074#4267074
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267074
16 years, 4 months
[JBoss AS Development] - Re: Naming over Remoting 3
by david.lloyd＠jboss.com
"wolfc" wrote : The most important bit herein is that the proxy itself should not contain any transport information. Whatever we put into JNDI is not fully aware of the network topology. Take for example a NAT firewall. In that case only the client knows how to communicate to AS. Although we could inform the server somehow, it is really outside of its scope.
The proxy would have to know some transport information. If it does not, there is no way for the client (or whoever reads the proxy from JNDI) to know where it's connecting back to, or how.
That said, the connection information (at least, as pertains to Remoting 3) could amount to "whatever connection this proxy came in on", and that'd probably be OK.
However, I don't see any sensible way we can get around having separate proxy implementations for IIOP/JRMP/Remoting/whatever.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267067#4267067
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267067
16 years, 4 months
[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC
by kabir.khan＠jboss.com
The problem is that in PreInstallAction, KernelControllerContext.setBeanInfo() adds the bean info and also describeVisits the metadata, while KernelMetaDataRepository.addMetaData() creates the MDR entry and updates the annotations. So with the way it is there is no MDR at the time we are in describeVisit.
| protected void installActionInternal(KernelControllerContext context) throws Throwable
| {
| KernelController controller = (KernelController)context.getController();
| Kernel kernel = controller.getKernel();
| KernelConfigurator configurator = kernel.getConfigurator();
|
| BeanMetaData metaData = context.getBeanMetaData();
| if (metaData.getBean() != null)
| {
| BeanInfo info = configurator.getBeanInfo(metaData);
| context.setBeanInfo(info);
| KernelMetaDataRepository repository = controller.getKernel().getMetaDataRepository();
| ClassLoader oldCL = SecurityActions.setContextClassLoader(context);
| try
| {
| repository.addMetaData(context); //1
| }
| finally
| {
| SecurityActions.resetContextClassLoader(oldCL);
| }
| try
| {
| applyScoping(context);
| }
| catch (Throwable t)
| {
| removeMetaData(context);
| throw t;
| }
| }
| }
|
If I call KCC.setBeanInfo() after KMDR.addMetaData() some of the exisiting tests like ClassAnnotationTestCase break. Now, the problem is that the internal calls to update the annotations return early since there is no bean info. I have worked around this with the following change locally:
| protected void installActionInternal(KernelControllerContext context) throws Throwable
| {
| KernelController controller = (KernelController)context.getController();
| Kernel kernel = controller.getKernel();
| KernelConfigurator configurator = kernel.getConfigurator();
|
| BeanMetaData metaData = context.getBeanMetaData();
| if (metaData.getBean() != null)
| {
| BeanInfo info = configurator.getBeanInfo(metaData);
| context.setBeanInfo(info);
| KernelMetaDataRepository repository = controller.getKernel().getMetaDataRepository();
| ClassLoader oldCL = SecurityActions.setContextClassLoader(context);
| try
| {
| repository.addMetaData(context);
| }
| finally
| {
| SecurityActions.resetContextClassLoader(oldCL);
| }
| try
| {
| applyScoping(context);
| }
| catch (Throwable t)
| {
| removeMetaData(context);
| throw t;
| }
| context.processMetaData();
| }
| }
|
KCC.setBeanInfo() now does not describeVisit() the metadata, instead an explicit call is needed to KCC.processMetaData()
| $svn diff kernel/src/main/java/org/jboss/kernel/plugins/dependency/AbstractKernelControllerContext.java
| Index: kernel/src/main/java/org/jboss/kernel/plugins/dependency/AbstractKernelControllerContext.java
| ===================================================================
| --- kernel/src/main/java/org/jboss/kernel/plugins/dependency/AbstractKernelControllerContext.java (revision 96585)
| +++ kernel/src/main/java/org/jboss/kernel/plugins/dependency/AbstractKernelControllerContext.java (working copy)
| @@ -177,10 +177,15 @@
| public void setBeanInfo(BeanInfo info)
| {
| this.info = info;
| - infoprocessMetaData();
| flushJBossObjectCache();
| }
|
| + public void processMetaData()
| + {
| + infoprocessMetaData();
| + flushJBossObjectCache();
| + }
| +
| public BeanMetaData getBeanMetaData()
| {
| return metaData;
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267059#4267059
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267059
16 years, 4 months