Practicing on bioinformatic progammes, and having trouble adding annotations in Artemis 18.2.0. Practicing on a contig, with a loaded entry from genemark with the coordinates of the CDS, into Artemis. Now I'm going to add annotation to the different CDS. Select a CDS --> edit --> Selected features in Editor --> Adds different qualifiers such as Genename and product under "Core". But from here, I am unable to press "ok" or "apply" after adding a qualifier.
I have a macbook
Tried to add different qualifiers, and change the "key", but the problem remains. Only able to press cancel
Related
I want to fetch values dynamically from properties so I have implemented one poc. In that poc I have declared one object with value in mule expression component. After that I am fetching the value key from properties file. It is showing exceptions while testing the application.
Exception MSG: Root Exception stack trace: unresolvable property or identifier: $
EX-1:
flowVars.deptCode=21432143;
property3=${flowVars.deptCode};
EX-2:
property3=${21432143};
In the above two examples ex-2 has worked fine and ex-1 has failed .
Please let me know if anyone have clarity on that.
Thanks,
Praveen
Mule is using Spring Properties which can be kept in a seperate properties file and then retrieved/used in your application via ${propertyName}.
A property placeholder is used to define where you keep those properties.
Ex 1 is not possible because properties are not aware at all of any variables or properties inside of your Mule application.
Another issue is that those files will be loaded when the application is started.
If you change the value of a property a restart of your application is needed, so your approach isn't going to work.
More info in the docs here:
https://docs.mulesoft.com/mule-user-guide/v/3.8/configuring-properties
You can use dataweave script to dynamically read values from property file
#[dw("p(flowVars.deptCode)")]
I have a JSF-App with two #ViewAccessScoped Beans and two Pages/Views, one Bean for a Search, on Bean for details. The details Bean references the #ViewAccessScoped so the data available when I go back to the Search. No other CDI-References. The WindowRenderMode is ClientWindowRenderMode.CLIENTWINDOW, no further configuration.
This works quite well so far. The Beans get un-scoped if i go to another page or logout. One Problem I Experienced:
When I open my details page in a new Browser tab, two new Beans are created, which is the expected Behavior. But when i close the tab, the Beans are still there. I guess the Server doesn't get notified when a tab get's closed.
Is there a built-in solution in deltaspike i can use to detect
tab clsoes?
Is there a Timeout for Beans with #ViewAccessScoped (beside the Session-Timeout)?
If there isn't a bulit-in solution: How can i programmatically un-scope my Beans? Preferably un-scope all Beans connected to that tab (=same Window-ID) (I'd detect the close my self with JavaScript and call a Bean-Method on close)
No, as it's not possible to catch a "tab close" event in JS.
See: javascript detect browser close tab/close browser
It was available in CODI but it was not migrated to DeltaSpike.
See: https://issues.apache.org/jira/browse/DELTASPIKE-437
You can do it via the WindowContext API:
#Inject private org.apache.deltaspike.core.spi.scope.window.WindowContext windowContext;
public void closeIt() {
windowContext.closeWindow("myWindowId");
}
I'm currently migrating existing components to use the HST-2 Spring Bean Bridge to integrate better with the Spring IOC container.
I followed the Hippo documentation and everything works as advertised, at least in the running site. I can now define my component beans in my spring configuration and use DI for my component dependencies.
However, I learned that now I cannot modify the parameters on those component's in the Channel Manager's Template Composer. Before migrating those catalog components to use the SpringBridgeHstComponent I could click in the component item area in the Template Composer and get the pop up dialog which let me view and edit all the parameters to that component item
(hst:parameternames, hst:parametervalues).
Now the pop up dialog just shows a message that
"No editable properties found for this component."
I should mention that the component parameter values that were already set on the components are still available during request processing/execution. But those values are now effectively "hard-coded" because the webmaster cannot view/change them in the Template Composer.
Is this a known issue with the SpringBridgeHstComponent? Or is there a workaround configuration or something to make those component parameters available again in the Channel's Template Composer?
The Hippo CMS Channel manager can only scan annotations in the component class configured by the hst:componentclassname property.
SpringBridgeHstComponent class itself, which is used in your component
configuration now, cannot be annotated by a domain-specific parameters
info annotation. As a result, it's not shown in the channel manager
properly.
If you want to enable the parameters setting window for the
SpringBridgeHstComponent-bridged component, then you should extend the
class only for the annotation. e.g, ContactSpringBridgeHstComponent
extends SpringBridgeHstComponent with a specific annotation in that
extending class for contact component for instance. See the docs for detail.
This is needed at the moment because channel manager recognizes the
parameters information only by class annotation, which makes you extend
a new class for each component.
I am currently going through Mkyong Spring 3.0 tutorial.
He goes on to clarify these 2 basic things.
1. Bean in different XML files
If you are referring to a bean in different XML file,
you can reference it with a ‘ref‘ tag, ‘bean‘ attribute.
2. Bean in same XML file
If you are referring to a bean in same XML file,
you can reference it with ‘ref‘ tag, ‘local‘ attribute.
The only thing I can make out is that the local attribute is not supported any more in version 4.1.5. For the timebeing, I have sticked to the
<ref bean="thebeaninstance"/>
and it works for both. <ref bean="..."> requires only it to be in the same context, or in a parent context.
But i am looking for something by which i will be able to resolve the difference once if somehow i encounter same ids in 2 different beans, and wish to refer to the one defined in different XML, since preference goes to the one defines in the same XML. Please suggest.
Spring dropped support for the local ref elements in version 4.0.1. This is from the notes:
Removed the ref 'local' attribute in spring-beans-4.0.xsd since 'local' lost its differentiating role to a regular bean ref back in the 3.1 days when we started allowing for the same bean id to reappear in a different beans section of the same configuration file (with a different profile). Issue: SPR-10437
See here: link
Basically, you should use the bean element.
Looking for a solution that will provide us more functionality within Spring properties such as:
nested structures
maps/lists
properties referencing other properties. Example:
city.name=Toronto
city.address=#{city.name}, 123 Ave SW
I tried EProperties (Google) and Commons Configurations (Apache) but doesn't seem to integrate very well with the Spring Framework.
Also, we're using Velocity to access properties using #springMessage("city.address"), so it needs to work for that.
Does anyone know how I can achieve the above by extending the default Properties capability?
With newest versions of Spring you can use the PropertySource mechanism. You register all your PropertySource and the order in which they are searched and then you don't have to do anything, except perhaps add this to your XML:
<context:property-placeholder />
As long as you declare only one of these without specifying local property files (the "old way"), you will be able to reference property A as the value of property B, even if they are not in the same property source.
For nested structures this may help if you don't like the properties readability:
https://stackoverflow.com/a/13470704/82609
For parsing problems you can easily handle lists and other stuff like that manually very easily:
Reading a List from properties file and load with spring annotation #Value