[Design of JBoss ESB] - Re: RemoteGatewayListener, RemoteFileSystemFactory, RemoteFi
by tfennelly
"Kevin.Conner(a)jboss.com" wrote : "tfennelly" wrote : These settings are used by the FtpImpl and SecureFtpImpl classes, which are RemoteFileSystem implementations. The are constructed from an EPR by the RemoteFileSystemFactory. Both implementations initialise their ftpLocalDir and ftpRemoteDir config settings from the jboessesb-properties.xml.
| I'll be very surprised if this is the case, are you certain of this? How could any of the ftp/sftp stuff work in that case. As already mentioned on the JIRA issue, it looks like the local dir is not getting passed through but the remote must be getting through otherwise it just wouldn't work.
FtpImpl and SecureFtpImpl are constructed from an EPR, but the ftpLocalDir and ftpRemoteDir settings are not coming from the EPR. They are being read from the jbossesb-properties.xml. Then... they construct a ConfigTree instance from the data read from the EPR + the data read from the jbossesb-properties.xml. The the configTree is used to initialize everything again and this is what I mean by toing and frowing :)
So, the code that I think is irrelevant (and should be removed) is the code in the RemoteGatewayListener class (71 to 77). It's setting ftpLocalDir and ftpRemoteDir on a ConfigTree instance (not the same instance I talk about above) and constructing an EPR from the ConfigTree. Bu the EPR doesn't support ftpLocalDir and ftpRemoteDir.
I was also thinking that setting these on the EPR was a bit strange and that it should be defined at the system level. I didn't say it in the last post, but since you seem to think the same thing then that's cool :)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240658#4240658
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240658
15 years, 6 months
[Design of EJB 3.0] - Re: EJBTHREE-1823 - handling of res-type in resource-ref
by jaikiran
anonymous wrote : So I think that JBoss should warn only if no "injection-target" is specified (though it can handle this case, too).
|
Yes, we can do away with the WARN message if the injection-target is configured.
anonymous wrote :
| And:
| "The resource manager connection factory type must be compatible with the type declared in the res-type element"
That's part of the "Deployer's responsibility" section :) So the container provider may or may not validate the types, which effectively might mean runtime exceptions in the application code where the code does a JNDI lookup and casts it to an incorrect type.
anonymous wrote :
| Even if I ...have an invalid res-type value, a lookup works.
I did not get this. You mean, you have something like this (just an pseudo example):
<resource-ref>
| <res-ref-name>MyDS</res-ref-name>
| <res-type>i.am.invalid.type</res-type>
| <mapped-name>java:/DefaultDS</mapped-name>
| </resource-ref>
|
|
Context ctx = new InitialContext();
| // successful lookup and cast
| DataSource ds = (DataSource) ctx.lookup("java:comp/env/MyDS");
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240638#4240638
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240638
15 years, 6 months
[Design of JBoss ESB] - Re: RemoteGatewayListener, RemoteFileSystemFactory, RemoteFi
by Kevin.Conner＠jboss.com
"tfennelly" wrote : This code is very interesting indeed :)
I suspect it is no different from the rest of the code ;)
"tfennelly" wrote : These settings are used by the FtpImpl and SecureFtpImpl classes, which are RemoteFileSystem implementations. The are constructed from an EPR by the RemoteFileSystemFactory. Both implementations initialise their ftpLocalDir and ftpRemoteDir config settings from the jboessesb-properties.xml.
I'll be very surprised if this is the case, are you certain of this? How could any of the ftp/sftp stuff work in that case. As already mentioned on the JIRA issue, it looks like the local dir is not getting passed through but the remote must be getting through otherwise it just wouldn't work.
As for the local dir, I'm not sure this should even be in the EPR to be honest as it should be specific to the local system. It would be better if this was being taken from jbossesb-properties.xml and defaulting to the value of java.io.tmpdir.
"tfennelly" wrote : It then loads this into a ConfigTree instance, calls checkParams, which goes and initializes the ftpLocalDir and ftpRemoteDir variables again from the configtree that was just constructed from the config. Huh?
Huh as in you are surprised or huh as in it appears to be doing it in a similar way to the others?
"tfennelly" wrote : I hope somebody sees the logic in all of this toing and frowing with the config!!
Not really, but it seems to be consistent with the rest of it. But then you know this as well as everyone else :)
"tfennelly" wrote : Anyway... does anyone know what the real intention is here? ftpLocalDir and ftpRemoteDir are currently being configured from the jbossesb-properties.xml.
Remote must be coming from the config, surely, although local doesn't really make sense.
"tfennelly" wrote : Was there ever an intention to allow this to be overridden by the EPR ala how it is currently being set in the configtree passed by the RemoteGatewayListener to the ListenerUtil.assembleEpr method?
The remote definitely, and I'm pretty sure this already works. The local doesn't make any sense to me :)
"tfennelly" wrote : As I see it, this code in RemoteGatewayListener is currently doing nothing. Can we just remove it and skip the EPR override that we don't have?
Which code are you referring to? Can you give line numbers?
"tfennelly" wrote : Also on this FTP code... looks to me like RemoteFileSystem instances are potentially being created for fun by (e.g.) the RemoteFileMessageComposer i.e. for every message. Is this really necessary, or can we just create one for the RemoteFileMessageComposer instance?
I'm sure there are many improvements to this code, like the others. I suspect the reason for this is more to do with the underlying connections and the lack of recovery in the original donation rather than anything else but file a JIRA for it.
Lets face it, the original code did not even understand how to construct a proper ftp URL, leaving us in the position where we can't easily fix it without breaking everything out there.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240625#4240625
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240625
15 years, 6 months