I need to find all messages described in a proto file.Is there some way to get the descriptor of all messages defined in a proto file??
In Java, given any type MyType defined in the file, you can do:
MyType.getDescriptor().getFile()
This returns a Descriptors.FileDescriptor which contains information about all types defined in the file.
Related
My property file name is dev_123.yaml.
dev is an environment variable called env.
123 is a value coming from query param called rollId. Am storing this value in vars.rollId.
In configuration properties component, under 'file' field it will work if I give ${env}_123.yaml.
However, I want to read the value of '123' dynamically via vars too. I tried the following but dint work:
#[p('env') ++ "_" ++ vars.rollId ++ ".yaml"]
${env}_${vars.rollId}.yaml
That will not work. Configuration properties and configuration files are resolved at the startup of a Mule application. Variables are defined during flow execution, after application startup. There is no way to set a variable during start-up. Using configuration properties in the properties file name works because they are resolved at the same time.
An alternative could be to create a custom Mule Module with Mule SDK that implements operations to read properties files dynamically during flow execution. You have to consider if it worth the effort.
The POSIX shm_open() function returns a file descriptor that can be used to access shared memory. This is extremely convenient because one can use all the traditional mechanisms for controlling file descriptors to also control shared memory.
The only drawback is that shm_open() always wants a filename. So I need to do this:
// Open with a clever temp file name and hope for the best.
fd = shm_open(tempfilename, O_RDWR | O_CREAT | O_EXCL, 0600);
// Immediately delete the temp file to keep the shm namespace clean.
shm_unlink(tempfilename);
// Then keep using fd -- the shm object remains as long as there are open fds.
This use of tempfilename is difficult to do portably and reliably. The interpretation of the filename (what the namespace is, how permissions are handled) differs among systems.
In many situations the processes using the shared memory object have no need for a filename because the object can be accessed more simply and safely by just passing a file descriptor from one process to another. So is there something that's just like shm_open() but can be used without touching the shared memory filename namespace?
mmap() with MAP_ANON|MAP_SHARED is great but instead of a file descriptor it gives a pointer. The pointer doesn't survive over an exec boundary and can't be sent to another process over a Unix domain socket like file descriptors can.
The file descriptor returned by shm_open() also doesn't survive an exec boundary by default: the POSIX definition says that the FD_CLOEXEC file descriptor flag associated with the new file descriptor is set. But it is possible to clear the flag using fcntl() on MacOS, Linux, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD and possibly other operating systems.
A library to solve the problem
I managed to write a library that provides the simple interface:
int shm_open_anon(void);
The library compiles without warnings and successfully runs a test program on Linux, Solaris, MacOS, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD and Haiku. You may be able to adapt it to other operating systems; please send a pull request if you do.
The library returns a file descriptor with the close-on-exec flag set. You can clear that flag using fcntl() on all supported operating systems, which will allow you to pass the fd over exec(). The test program demonstrates that this works.
Implementation techniques used in the library
The readme of the library has very precise notes on what was done and what wasn't done for each OS. Here's a summary of the main stuff.
There are several non-portable things that are more or less equivalent to shm_open() without a filename:
FreeBSD can take SHM_ANON as the pathname for shm_open() since 2008.
Linux has a memfd_create() system call since kernel version 3.17.
Earlier versions of Linux can use mkostemp(name, O_CLOEXEC | O_TMPFILE) where name is something like /dev/shm/XXXXXX. Note that we are not using shm_open() at all here -- mkostemp() is implicitly using a perfectly ordinary open() call. Linux mounts a special memory-backed file system in /dev/shm but some distros use /run/shm instead so there are pitfalls here. And you still have to shm_unlink() the temp file.
OpenBSD has a shm_mkstemp() call since release 5.4. You still have to shm_unlink() the temp file but at least it is easy to create safely.
For other OSes, I did the following:
Figure out an OS-dependent format for the name argument of POSIX shm_open(). Please note that there is no name you can pass that is absolutely portable. For example, NetBSD and DragonFlyBSD have conflicting demands about slashes in the name. This applies even if your goal is to use a named shm object (for which the POSIX API was designed) instead of an anonymous one (as we are doing here).
Append some random letters and numbers to the name (by reading from /dev/random). This is basically what mktemp() does, except we don't check whether our random name exists in the file system. The interpretation of the name argument varies wildly so there's no reasonable way to portably map it to an actual filename. Also Solaris doesn't always provide mktemp(). For all practical purposes, the randomness we put in will ensure a unique name for the fraction of a second that we need it.
Open the shm object with that name via shm_open(name, O_RDWR | O_CREAT | O_EXCL | O_NOFOLLOW, 0600). In the astronomical chance that our random filename already exists, O_EXCL will cause this call to fail anyway, so no harm done. The 0600 permissions (owner read-write) are necessary on some systems instead of blank 0 permissions.
Immediately call shm_unlink() to get rid of the random name. The file descriptor remains for our use.
This technique is not quaranteed to work by POSIX, but:
The shm_open() name argument is underspecified by POSIX so nothing else is guaranteed to work either.
I'll let the above compatibility list speak for itself.
Enjoy.
No, there isn't. Since both System V shared memory model and POSIX shared file mapping for IPC require operations with a file, there is always need for a file in order to do mapping.
mmap() with MAP_ANON|MAP_SHARED is great but instead of a file
descriptor it gives a pointer. The pointer doesn't survive over an
exec boundary and can't be sent to another process over a Unix domain
socket like file descriptors can.
As John Bollinger says,
Neither memory mappings created via mmap() nor POSIX shared-memory
segments obtained via shm_open() nor System V shared-memory segments
obtained via shmat() are preserved across an exec.
There must be a well-known place on the memory to meet and exchange information. That's why a file is the requirement. By doing this, after exec, the child is able to reconnect to the appropriate shared memory.
This use of tempfilename is difficult to do portably and reliably. The interpretation of the filename (what the namespace is, how permissions are handled) differs among systems.
You can have mkstemp create a unique filename in /dev/shm/ or /tmp and open the file for you. You can then unlink the filename, so that no other process can open this file, apart from the process that have the file descriptor returned from mkstemp.
mkstemp(): CONFORMING TO 4.3BSD, POSIX.1-2001.
Why not creating it with access rights to 0?
Thus no process would be able to "open" it and let you unlink it safely just after?
Is there any API's or documentation to facilitate in parsing the authorization file for X server?
I am using xcb to connect to a display. It accepts a xcb_auth_info_t struct for authorization info. However, I cannot find any information on how to build this structure. There doesn't seem to be any documentation on the format of the X server authorization files.
Solution I settled with:
It turns out, for MIT-MAGIC-COOKIE-1 type X authority files, the Xauth structure (from X11/Xauth.h) members map directly to the xcb_auth_info_t members. So, just read an Xauth structure from your X authority file using XauReadAuth. Then copy over the name, name_length, data, and data_length members.
If you want a more portable way to parse the X authority file, you can refer to xcb's source code. It is pretty messy, but it shouldn't be too difficult to adapt their source code for your own purposes. Refer to xcb_util.c for details on how to open a socket to a display. Once you have the socket, you can use methods from xcb_auth.c to create the xcb_auth_info_t struct (see the methods _xcb_get_auth_info, get_auth_ptr, and compute_auth).
I only needed to connect through unix sockets (AF_UNIX), so the code I ported over was fairly minimal. I mostly just used the compute_auth method (and its dependencies).
The authorization protocols and files are discussed briefly in the xauth and Xsecurity manual pages, and in more detail in those for the Xau library functions (XauWriteAuth etc.). The xcb_auth_info_t structure appears to be defined in the /usr/include/xcb/xcb.h file as follows:
/**
* #brief Container for authorization information.
*
* A container for authorization information to be sent to the X server.
*/
typedef struct xcb_auth_info_t {
int namelen; /**< Length of the string name (as returned by strlen). */
char *name; /**< String containing the authentication protocol name, such as "MIT-MAGIC-COOKIE-1" or "XDM-AUTHORIZATION-1". */
int datalen; /**< Length of the data member. */
char *data; /**< Data interpreted in a protocol-specific manner. */
} xcb_auth_info_t;
After some searches, it is like you doesn't have to build this structure yourself. Looks at this discussion:
What's the right way to call xcb_connect_to_display_with_auth_info() given a Xauthority file
The Xauthory file is specified in the XAUTHORITY environement variable. This file is generated by the program that start the X server (xdm, startx or xauth itself for example according to the doc in man xauth)
A classical connection with auth file specified via the XAUTHORITY variable works like this :
xcb_connect call xcb_connect_with_auth_info() with a auth info set as NULL
xcb_connect_with_auth_info() call _xcb_get_auth_info() in order to get auth information from the default xauthority file.
If you really want to see how this function get the auth info:
git clone git://anongit.freedesktop.org/xcb/libxcb
Look at the file ./libxcb/src/xcb_util.c lines 478 to end
Look at the file ./libxcb/src/xcb_auth.c lines 312 to 379 for _xcb_get_auth_info()
I have finally gotten my Flash Builder to look at my remote services but now I have a problem that my Remote information, which should be the same except for alot more entries, just displays each object with the title [object Object] I have had a look around and I see if I test the service out locally, it is working as it calls all the information under Response Name 'object and Response Value 'Object'
On my localhost configuration this shows the name which is inside my Object items. How can I fix this?
[object Object] is the result of the toString() method of Object. If you get this it probably means your custom object type is being returned as a generic object from the remote AMF service. A lot of things could be the cause of this. Here are a few to check:
1) Make sure that your custom object type is compiled into the app. IF the object is never used explicitly the Flex compiler will not put it in the final SWF. You can do this by creating a fake variable:
private var myUnusedObject : MyCustomObjectType;
Or, I believe, there is a compiler flag to force unused classes to be compiled into the SWF.
2) You may have to add a formal mapping on your server. This depends primarily on what server side tech you're using. In AS3 you add a RemoteAlias metadata to the class. In ColdFusion you use the alias tag on the cfcomponent tag. I believe in WerbORB.NET I had to add the mapping in an XML Config file [but it's been years since I've done that]. I assume alternate technologies use similar approaches.
3) Check case sensitivity on the path names for your server code and make sure that the aliases (mentioned in 2) match.
4) In ColdFusion AMF you have to make sure that your public properties and types match up. They must be in the same order in your AS3 class as they are in your remote CFC. The property types must match. String to String; Boolean to Boolean, etc... I assume other AMF implementations have similar restrictions.
I have a BizTalk 2009 send port that uses the %datetime_bts2000% macro in the file name. When I look at the tracked message event, I don't get the name of the actual file that was sent. I thought I could get it from the context property:
OutboundTransportLocation
SFTP://xxx#xxxx.xxx.com:22/Inbound/Encrypted/xxx.xxx.xxx.201101280410324
Promoted
http://schemas.microsoft.com/BizTalk/2003/system-properties
It turns out that the date is equivalent to my deployment date... not the actual date time stamp of the sent file.
Where do I find the actual filename generated by the Macro?
I happen to agree with #Bryan. I have in fact created such a pipeline to preserve OR set the attachment file name explicitly in a pipeline that I use for email.