Hi Indika, Ruwan, Thanks for the reply. I have understood something that I was trying to understand; the difference for having two clearly different mechanisms of pulling resources from a Registry. Currently, we do have a static 'fetch @ start' mechanism, so that I believe the caching would infact incur an overhead. We are looking forward to implement the fully dynamic look-up during this week and I believe that this post saved a lot of our time. Also, few minor clarifications.
I understand that the mechanism Indika explains can be used to retrieve an InputStream for a non-XML resource on the Registry which can be manipulated inside our code. However, are there similar utilities to extract an OMNode, for an XML-resource in the same manner? also is there any API which is helpful in deciding whether the stream is non-XML or XML. As of now, I have manged to do all these using the *public OMNode lookup(String key)* method based on the content I read back. Will the class-mediator properties be able to dynamically read from the Registry based on a key? Is this a TODO for the future release? If so, perhaps we can invest some time in implementing this feature for the class mediator properties instead of focusing on a project specific implementation, since the APIs are generic, according to what I understand from this discussion. Thanks, Senaka 2008/8/11 Indika Kumara <[EMAIL PROTECTED]> > Hi Senaka > > *public OMNode lookup(String key)*, only imply that for a given key you > will get a resource as a OMNode . You will not get any guarantee that some > other registry implementation will handle binary and pain text as the way we > are handling now. For example, someone can ignore completely binary and pain > text and return null if he only wants to use xml content or someone may > wraps the OMText with another OMElement and return that OMElement as result. > Very simply, *public OMNode lookup(String key) *never expose the > restriction to make sure that binary content and plain text content are > always wrapped inside a OMText as it is completely implementation specific. > > But one guarantee, currently all registry implementation behave as you > expected. > > We discourage to use lookup(String key) method . Instead, you should use > *public > Object getResource(Entry entry) *method to access registry resources . It > is the method that implements "the core Registry lookup algorithm". All the > caching at registry level will do there. Please look at that. > (AbstractRegistry) > > You can use that API as follows > > Entry entry = new Entry(key); > > entry.setType(Entry.REMOTE_ENTRY); > > regsirty.getResource(enrty); > > Entry has methods to set cache expiryTime , etc. > > If you can cache entry in somewhere, you can use it whenever you need to > access content of the resource. In synapse , we are caching those at > SynapseConfiguration. > > To ensure that binary and text content would be accessed in a consistent > way with any registry implementation, we can move, the logic of binary > content handling to the *getResource(Entry entry) *where the lookup > algorithm has been already there. By doing that we can enforce that all > registry implementation will behave in a consistent way (binary and text > content handling and lookup algorithm). > > Then we have to change > > public Object lookup(String key); > > To > > public InputStream lookup(String key); > > This is just for avoiding misusing lookup(String key) method . Now , this > method is not depended on implementation ...always return a Stream > > Actually, in the current implementation, if you are using this method, > there is no caching, no entry mapping to endpoint, and sequence at registry > level, etc. To get that, you have to use *getResource(Entry entry)*. > Actually, lookup method is a just helper method to *getResource(Entry > entry)* . Within, SynapseConfiguration, we only use *getResource(Entry > entry)*. > > In additions, to ensure that resource handling is consistent, we have two > options, > > We can make Registry interface is an abstract class and add > *getResource(Entry > entry) *implementation to that and make that method as final. Then, any > registry implementation have to extend this and cannot override > *getResource(Entry > entry) *as it final. And also this add is-a relationship. > > We can make existing method of getResource(Entry entry) implementation at > AbstractRegistry as a final method so that it cannot be overridden. Then, it > needs to document that use AbstractRegistry and extend it instead of > implementing Registry interface, whenever write a registry implementation. > > One thing to note, To covert a object into a Stream , you can use > SynapseConfigUtils. getInputStream(Object o) . Please look at that. > > Then code look like... > > Entry entry = new Entry(key); > > entry.setType(Entry.REMOTE_ENTRY); > > Object resource = regsirty.getResource(enrty); > > InputStream in = SynapseConfigUtils. getInputStream(resource); > Thanks > Indika > > Senaka Fernando wrote: > > Hi Indika, > > Yep, the latest fix seem to solve my problem. Btw, one more question. I > managed to read the contents of the DataHandler in the following manner. > > OMNode textNode = registry.lookup(registryKey); > DataHandler dh = (DataHandler)(((OMText)textNode).getDataHandler()); > BufferedReader br = new BufferedReader(new > InputStreamReader((InputStream)(dh.getContent()))); > > Do all Registries implemented by WSO2ESB or any in the future do confirm to > this layout? That means, am I certain that I can read non-XML content from > any registry in this manner? > > Thanks, > Senaka > > 2008/8/10 Indika Kumara <[EMAIL PROTECTED]> > >> Hi Senaka >> >> There was an issue as there are no parent for wrapping OMText Element that >> used to wrap binary and plain text as a DataHandler. As I can remember , I >> had tested this scenario when I was adding handling binary and plain text . >> But , there was no result.detach() method at that svn revision. It seems >> that this (result.detach()) was added for fixing an issue and after that it >> seems to forget to test a scenario accessing resources with binary and plain >> text content. >> >> I have fixed this and update sample 350 to demonstrates this. That sample >> use Java script files in native form. >> >> Please update both synapse and ESB source and try out your scenario again. >> >> Thanks >> Indika >> >> Senaka Fernando wrote: >> >> Hi all, >> >> Recently when working on the ESB Registry, >> (org.wso2.esb.registry.ESBRegistry), I discovered that I can quite easily >> obtain the contents of an XML file using a lookup(String). According to the >> implementation, it also seems to handle non-XML file types (ex:- .txt) as >> well, and creates a OMText along with the file attached as a DataHandler to >> it. Did I get this correct? or am I mistaken? >> >> If I got it right, it works fine upto, result.detach(). At this point I >> get an exception, >> >> org.apache.axiom.om.OMException: Elements that doesn't have a parent can >> not be detached >> at >> org.apache.axiom.om.impl.llom.OMNodeImpl.detach(OMNodeImpl.java:195) >> at org.wso2.esb.registry.ESBRegistry.lookup(ESBRegistry.java:207) >> at >> org.sciflex.plugins.synapse.esper.mediators.AxiomMediator.mediate(AxiomMediator.java:221) >> at >> org.apache.synapse.mediators.ext.ClassMediator.mediate(ClassMediator.java:78) >> at >> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58) >> at >> org.apache.synapse.mediators.filters.FilterMediator.mediate(FilterMediator.java:95) >> at >> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58) >> at >> org.apache.synapse.mediators.filters.InMediator.mediate(InMediator.java:60) >> at >> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58) >> at >> org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:125) >> at >> org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:176) >> at >> org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:89) >> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:170) >> at >> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) >> at >> org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWorker.java:244) >> at >> org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:185) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) >> at java.lang.Thread.run(Thread.java:619) >> >> It might most probably be that I'm making a mistake here. If so, can you >> please tell me how I could for instance read a .txt file that I save in the >> ESBRegistry? >> >> Thanks, >> Senaka >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.138 / Virus Database: 270.6.0/1602 - Release Date: 8/9/2008 >> 1:22 PM >> >> >> ------------------------------ >> >> _______________________________________________ >> Esb-java-dev mailing [EMAIL >> PROTECTED]://mailman.wso2.org/cgi-bin/mailman/listinfo/esb-java-dev >> >> >> >> _______________________________________________ >> Esb-java-dev mailing list >> [email protected] >> http://mailman.wso2.org/cgi-bin/mailman/listinfo/esb-java-dev >> >> > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > > Version: 8.0.138 / Virus Database: 270.6.0/1603 - Release Date: 8/10/2008 > 6:13 PM > > > ------------------------------ > > _______________________________________________ > Esb-java-dev mailing [EMAIL > PROTECTED]://mailman.wso2.org/cgi-bin/mailman/listinfo/esb-java-dev > > > > _______________________________________________ > Esb-java-dev mailing list > [email protected] > http://mailman.wso2.org/cgi-bin/mailman/listinfo/esb-java-dev > >
_______________________________________________ Esb-java-dev mailing list [email protected] http://mailman.wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
