Camel Custom Component - components

Is this possible?
<bean id="camelCustomComponent" class="x.y.z.CustomComponent" />
Below is the camel route
<to uri="camelCustomComponent:someThing?SomeParams=someValues" />
This is to leverage the camel component user/developer to use their name whatever they want.
I understand their should be a file with name camelCustomComponent which will have the Custom Component's class name.
Can we make dynamic.
Is it possible to initialise the component dynamically?
Thanks.
Regards
Senthil Kumar Sekar

I see two options.
Create a full component as per the Writing Components guide, the important point being that you will need to create a file under META-INF/services for your camelCustomComponent: URI to be detect by Camel.
Use the Bean Component which has some support for setting method parameter values. See the section titled Parameter binding using method option

Yes as bgossit posted, see the documentation about writing a component
http://camel.apache.org/writing-components.html
And the options in the uris, are just getter/setter in the endpoint class. That is all you need to do.
You can for example copy an existing component and use that for creating your own, for example if the component is similar to yours.
But better yet, maybe use the maven archetype to create a new component as documented here
http://camel.apache.org/camel-maven-archetypes.html

Related

What is the "binding" property of controls and how do you use it?

The "binding" basic property is described as a property that "Specifies an expression that binds a control to a particular control property". I tried to google and read at HCL docs but there is no example on how to use it.
The binding property allows you to specify an object property (say, on a managed bean or dataContext) that will be set to the specified component. For example, you could do:
<xp:inputText binding="#{someBean.textField}"/>
...and that would call someBean.setTextField(XspInputText inputText).
All that said, it's kind of an edge-case property. I've made good use of it, but it's largely an artifact of earlier JSF revisions, when it was more common to have backing logic that "knew" about the front-end XPage explicitly.
In general, it's better design to stick to value bindings like value="#{someBean.firstName}" and not make your backing objects aware of the front-end UI, unless you have an explicit reason to do otherwise.

Spring Integration - modifying one property of the payload

In my SI flow I want to modify one property of the payload. At the beginning of the flow I populate a Java bean (let's call it MyFlowBean) and I send it via the difference components of the flow.
At one point I want to alter the property 'extractedValue' of this bean and I want to do it in the right way. I mean I am sure there is a component (a transformer??) where I can say e.g.
<transform propert='payload.extractedValue' value='[spEl expression]' />
Ok, I know there isn't such a tag in SI, it was just a sample.
Also I could achieve it with serviceActivator but it doesn't seem right to me to write a Java class that contain 2 lines of code and use this class in the service activator.
It has to be more elegant way.
Thanks,
V.
The Content Enricher pattern is for your and respectively the <enricher> component is present in the Spring Integration to achieve the desired goal:
<enricher>
<property name="extractedValue" expression="[spEl expression]"/>
</enricher>

How to override default spring integration configuration

For example:
xmlns:int-jdbc="http://www.springframework.org/schema/integration/jdbc"
<int-jdbc:inbound-channel-adapter.......
I want this to use my custom implementation, so i need to know
1) What class it uses (so i can extend it and override whatever)
2) than how do i tell it to use my new class rather than the default one.
is this possible?
Thanks
There is currently no way to inject your own implementation using the XML namespace, but you can simply wire up <bean/> definitions. After all, that's all that the namespace parser does.
In this case, you need a bean of class SourcePollingChannelAdapterFactoryBean which needs PollerMetadata and a source (and creates a SourcePollingChannelAdapter), with the source being a bean of class JdbcPollingChannelAdapter (which is a MessageSource).
So you would subclass the JdbcPollingChannelAdapter.
If you think your implementation will have wide appeal, please open a JIRA issue and consider contributing it.

how can I access endpoint properties set in faces-config.xml programmatically?

I am using the IBM Social Business Toolkit. I have defined a connection for my Notes app via endpoints in the faces-config xml file. I wonder how I can access this file pro grammatically since I could not find a service that returns me the base url of IBM Connections.
It's useful to remember that an endpoint definition is really just creating a managed bean. The managed bean has a variable name you refer to it - the managed-bean-name property. You can access this directly from SSJS or via ExtLibUtil.resolveVariable() in Java. The definition also tells you the Java class that's being used, e.g. com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint. That really gives you all the information you need to get or set the properties.
So from SSJS you can just cast it to the class name, e.g.
var myService:com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint = connections
So the bit after the colon will be the managed-bean-class value and the bit after the equals sign will be the managed-bean-name. In Java, you can use
ConnectionsBasicEndpoint myService = (ConnectionsBasicEndpoint) ExtLibUtil.resolveVariable(ExtLibUtil.getXspContext().getFacesContext(), "connections");
You'll then have access to all the methods of the class, so you should be able to retrieve what you need.
The properties are part of the Java class, who are referred to in the Faces-Config.xml. So get the class by his fully qualified name or by bean name and set or get the properties
I think the best route will most likely be what Paul is suggesting: resolve the variable by its name and use the getters to get the effective properties that way.
Sven's suggestion is a good one to keep in mind for other situations. By accessing the faces-config.xml file as a resource, you could load it into an XML parser and find the values using XPath. I'm doing much that sort of technique in the next version of the OpenNTF Domino API, which will have a set of methods for manipulating the Faces config. However, one key aspect there is that reading the XML file directly will just get you the string values, which may be EL expressions, whereas going the resolveVariable route will get you the real current properties.

Customize DataService namespace and EntityContainer

Nutshell: The Entity Framework Provider for WCF Data Services pulls the schema namespace and EntityContainer name directly from the namespace and class name of the DbContext, respectively. This is also true for DbContexts that are developed using the code-first method.
Is there a way to modify this provider behavior a posteriori--that is, without modifying the class name or the EDM(X)?
Background/caveats/opinion: This is a handy behavior for prototyping, but in a production scenario, the class name is itself an implementation detail that should be hidden from service consumers.
Further, in my case the name cannot be changed, since I am using a framework that provides a very generic DbContext that I am then composing/extending.
Note that I am not discussing a way to create more "space" between the CLR and EDM representations of the data model. Rather, I'm looking for a way to modify the behavior of the DataService<T> extension itself, so that the internal CLR namespace and DbContext extension class name (preserved in the EDM, which is totally okay) aren't exposed externally.
The specific customization points in the service metadata (custom-ns and custom-container below):
<edmx:Edmx Version="1.0" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx">
<edmx:DataServices m:DataServiceVersion="1.0" m:MaxDataServiceVersion="3.0" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<Schema Namespace="<custom-ns>" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
<EntityType Name="EgEntity">
.
.
.
</EntityType>
.
.
.
<EntityContainer Name="<custom-container>" m:IsDefaultEntityContainer="true">
<EntitySet Name="EgEntity" EntityType="<custom-ns>.EgEntity" />
.
.
.
</EntityContainer>
</Schema>
</edmx:DataServices>
</edmx:Edmx>
In code-first, you can specify the schema for tables in the SSDL with the Table annotation (look at the Schema property). Unfortunately, I don't think you can overwrite the schema namespaces used in the CSDL with either attributes or the model builder (please note that I haven't extensively researched this).
You may attempt to play with namespace aliases, although I'm not sure this would work as you intend.
In model-first and database-first, see this question which seems to answer yours. Let me know if it doesn't.
I realize this answer is not too helpful, but I would like to suggest that you specify proper namespaces for your codebase, even (especially) for production. This is because I can't immediately see why a namespace should be "hidden" in any normal scenario, but please do expand on your use-case if you disagree.
That being said, I agree that one should be able to map proper CLR namespaces to different EDM schemas for other reasons, I guess everybody is OK with using the same names as long as they make sense. By the way, don't forget vendor prefixes, especially since you're exposing these names to the network.
Note that the third-party framework namespace shouldn't be relevant as long as the context class is not sealed. Usually, entities are defined as POCOs so that's normally not a problem either. Thus, the standard solution would be to extend this generic context class in a namespace of your own, along with the entities.

Resources