tag:blogger.com,1999:blog-6710986841844568686.post4927574298635128916..comments2024-03-28T00:21:25.383-07:00Comments on Java Configuration: A Proposal for Java EE ConfigurationAnonymoushttp://www.blogger.com/profile/08634170528353247173noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-6710986841844568686.post-33777613993808280312022-03-19T01:03:56.765-07:002022-03-19T01:03:56.765-07:00Nice information, valuable and excellent design, a...Nice information, valuable and excellent design, as share good stuff with good ideas and concepts, lots of great information and inspiration, both of which I need, thanks to offer such a helpful information here.<br /><a href="https://www.wikitechy.com/full-form/ibm-full-form" rel="nofollow">ibm full form in india</a> |<br /><a href="https://www.wikitechy.com/full-form/ssb-full-form" rel="nofollow">ssb ka full form</a> |<br /><a href="https://www.wikitechy.com/full-form/dp-full-form" rel="nofollow">what is the full form of dp</a> |<br /><a href="https://www.wikitechy.com/full-form/brics-full-form" rel="nofollow">full form of brics</a> |<br /><a href="https://www.wikitechy.com/full-form/gnm-full-form" rel="nofollow">gnm nursing full form</a> |<br /><a href="https://www.wikitechy.com/full-form/bce-full-form" rel="nofollow">full form of bce</a> |<br /><a href="https://www.wikitechy.com/full-form/php-full-form" rel="nofollow">full form of php</a> |<br /><a href="https://www.wikitechy.com/full-form/bhim-full-form" rel="nofollow">bhim full form</a> |<br /><a href="https://www.wikitechy.com/full-form/nota-full-form" rel="nofollow">nota full form in india</a> |<br /><a href="https://www.wikitechy.com/full-form/apec-full-form" rel="nofollow">apec full form</a> logeshhttps://www.blogger.com/profile/02217727340222751662noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-21814121674086828512020-07-12T06:33:56.594-07:002020-07-12T06:33:56.594-07:00You have provided a nice article, Thank you very m...You have provided a nice article, Thank you very much for this one. And I hope this will be useful for many people. <a href="https://www.crsinfosolutions.com/salesforce-training-india/" rel="nofollow"> Salesforce Training India</a> Austinhttps://www.blogger.com/profile/07295300710332423899noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-79219486744931373172016-01-09T05:12:19.054-08:002016-01-09T05:12:19.054-08:00Great Article
Java Online Course | Java EE Traini...Great Article<br /><a href="http://wisenitsolutions.com/IT-Courses/Java-Training" title="Java Online Course" rel="nofollow">Java Online Course</a> | <a href="http://wisenitsolutions.com/IT-Courses/JavaEE-Training" title="Java EE Training" rel="nofollow">Java EE Training</a> <br> <br> <br> <a href="http://wisentechnologies.com/it-courses/java-training.aspx" title="Java Training Institutes in Chennai" rel="nofollow">Java Training Institutes in Chennai</a> | <a href="http://wisentechnologies.com/it-courses/java-training.aspx" title="java j2ee training institutes in chennai" rel="nofollow">java j2ee training institutes in chennai</a> | <a href="http://wisentechnologies.com/it-courses/java-training.aspx" title="Java Training in Chennai" rel="nofollow">Java Training in Chennai</a> | <a href="http://wisentechnologies.com/it-courses/java-training.aspx" title="J2EE Training in Chennai" rel="nofollow">J2EE Training in Chennai</a> | <a href="http://wisentechnologies.com/it-courses/java-training.aspx" title="Java Course in Chennai" rel="nofollow">Java Course in Chennai</a> <br> <br> <br> <a href="http://java360.co.in/java-interview-questions/" title="Java Interview Questions" rel="nofollow">Java Interview Questions</a> | <a href="http://javatraininginstitutes.com" title="Java Training Institutes" rel="nofollow">Java Training Institutes</a> | <a href="http://www.athene.co.in/2016/01/core-java-interview-question.html" title="Core Java Interview Questions" rel="nofollow">IT Technical Articles</a> <br />for ict 99https://www.blogger.com/profile/01234222908168002434noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-51051562568642657522014-05-25T11:53:04.534-07:002014-05-25T11:53:04.534-07:00Hi Arjan
I also would say the most easy way of in...Hi Arjan<br /><br />I also would say the most easy way of integration is providing the existing deployment descriptors using the configuration mechanism, e.g. as InputStreams or Strings.This still allows us to store them at any kind of location (deployed with ear, from the file system or any remote location, including databases etc). The according value in the store simply defines the location, where the descriptor is stored. An according resolver/adapter then models the bridge between the descriptor and the effective deployment descriptor(s) (and even could additional dynamic behaviour as useful).<br /><br />Or we can use EL ${expression}. In Credit Suisse, we have such a mechanism in place, e.g. for<br />- redirecting entries to other entries, including considering stage specific entries.<br />- decryption of encrypted configuration values, e.g. passwords or sensitive links.<br /><br />I am personally open, which of the different variants would be used, because all at the end allow to configure an application externally. The EL mechanism is needed anyway, and easy to understand, so it would be probably sufficient.<br /><br />Given that, a (single) web.xml e.g. could be accessed as<br /><br /> String webXml = config,getText("javax.servlet.web.xml.myappid");<br /><br />With web fragments things get a bit more complicated, but the principle remaind the same, e.g.<br />(one way to achive this):<br /><br /> int fragmentCount = config.getInteger(javax.servlet.web.xml.myappid.count",0);<br /> for(int i=0; i< fragmentCount; i++){<br /> String webXml = config,getText("javax.servlet.web.xml.myappid." + i);<br /> }<br />Anonymoushttps://www.blogger.com/profile/08634170528353247173noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-10569342216732201832014-05-21T23:16:41.980-07:002014-05-21T23:16:41.980-07:00About integration of the Config JSR with the EE st...About integration of the Config JSR with the EE stack there is also an interesting discussion with Antoine Sabot-Durant if CDI 2.0 would be capable of being the main container/integration architecture for EE8, see <a href="https://t.co/redirect?url=http%3A%2F%2Ft.co%2FO6UQaGiTZJ&t=1&sig=a49db8f8752c30bdae3a73723f791915b597913a&iid=73dbe1d4b8724d01a95c8b5d0fe5c000&uid=1038110960&nid=136+1028" rel="nofollow">https://t.co/redirect?url=http%3A%2F%2Ft.co%2FO6UQaGiTZJ&t=1&sig=a49db8f8752c30bdae3a73723f791915b597913a&iid=73dbe1d4b8724d01a95c8b5d0fe5c000&uid=1038110960&nid=136+1028</a>Anonymoushttps://www.blogger.com/profile/08634170528353247173noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-19888444368168997372014-05-19T08:36:36.243-07:002014-05-19T08:36:36.243-07:00David/Anatole - cheers, the typesafe approach to d...David/Anatole - cheers, the typesafe approach to defaults looks very sensible.<br /><br />Anatole - thanks for clarification on the other points as well, and sorting conflicts via a resolution mechanism (at deploy time) makes a lot of senseAnonymoushttps://www.blogger.com/profile/14427824614189918270noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-35673936879083638762014-05-18T16:11:11.675-07:002014-05-18T16:11:11.675-07:00Hi Daniel
about your points:
"Can configura...Hi Daniel<br /><br />about your points:<br /><br />"Can configuration be updated at runtime, and what's the expected behaviour (I assume this would be JSR-specific?)"<br />-> Mutable configuration is a requirement. There are different use <br /> cases: <br />1) the configuration is updated (if it is not read-only), <br /> e.g. using put, remove programmatically.<br />2) the configuration is updated by internal changes, <br /> e.g. changes on the remote representation.<br /><br />-> In both cases, according ConfigurationChangeEvent must be <br /> provided to all interested parites, also containing a detailed list of the changes done.<br />-> Listeners can then react as needed.<br />-> I suggest configuration can be serialized, so it guaranteed, that a <br /> configuration state can be transferred over the network. The same <br /> must be true for the change events.<br /><br />"How are config updates managed and coordinated in a distributed (cloud?) environment"<br />-> I do not think, that the JSR can cover these aspects directly. But <br /> the mechanisms above help definitively implementing such <br /> features relatively easily...<br /><br />"Providing 'sensible defaults' is often very challenging in my opinion"<br />-> what makes sense is typically a problem issue, not a design <br /> issue.<br />-> defaults can added within the code that consumes the according <br /> configuration in the CP<br />-> defaults can be defined externally<br />-> defaults can be even dynamic.<br />-> How far will end up in the final spec, is open. The current GitHub <br /> repo already supports all the scenarios above.<br /><br />*Hierarchy, overriding and namespace collision are also a big concern. If library developers include config in their JAR with a namespace that collides with others, how is this handled? Is the order of loading an issue?*<br />-> By default I would definitively not try to handle it implicitly or <br /> based on order, but see it as a deployment problem.<br />-> a feasible resolution mechanism makes sense<br />-> but what will be part of the final spec, and what will be part of the <br /> RI, also here will be to be discussed.<br /><br />In general aspects, where it is difficult to find common sense, are good candidates to not include into the spec, but allow/support for flexibility in the implementation. If best practives evolve over time, additional aspect may go into the standard in a later release. Also given the timeline, we must be careful, what will effectively end up in the final JSR's scope.<br />From my point of view the basic configuration mechanism, its Java API, common parts of the SPI (access and annotations) and all EE related services should be part of the JSR, since these are all the aspects application programmers and server developers will have to deal with. More special or arguable aspects nevertheless may end up as part of the RI and not (yet) specfified.Anonymoushttps://www.blogger.com/profile/08634170528353247173noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-46023247707385647812014-05-18T15:49:07.135-07:002014-05-18T15:49:07.135-07:00Yep, default handling is done nice there, I would ...Yep, default handling is done nice there, I would even add one variant: pass it along the method accessing the config value, e.g. instead of accessing <br /><br /> get("foo"); <br /><br />you may write <br /><br /> get("foo", "defaultFooValue");<br /><br />The same would also work with adapters for type safe configuration.<br /><br />Basically IMO Java configuration must be multi-format capable. It may define a default format to be used, so there is at least one existing format that developers know they can use. Given a useful extension SPI, other third parties should be enabled to provide additional formats as needed. What will end up as part of the API/spec and what will be just an implementation aspect (RI) will for sure be a topic for the expert group.Anonymoushttps://www.blogger.com/profile/08634170528353247173noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-15401655184686900972014-05-18T03:17:35.188-07:002014-05-18T03:17:35.188-07:00The typesafe config library (used by Play2) has a ...The typesafe config library (used by Play2) has a nice pattern for defaults [1] and overriding.<br /><br />IMO it's worth separating an effort to define text based key/vale config formats with an effort to define an API - bundling them together will probably make it harder to extend the number of backends available. <br /><br /><br />[1] https://github.com/typesafehub/config#how-to-handle-defaultsDavid Illsleyhttps://www.blogger.com/profile/18084679536639980435noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-31502886097895808592014-05-17T11:15:58.759-07:002014-05-17T11:15:58.759-07:00In general I like the proposal Anatole, and the KI...In general I like the proposal Anatole, and the KISS-based key/value approach appears the correct method IMHO<br /><br />Arun also makes some great points in his post; +1 especially for the REST API and learning from other modern web frameworks<br /><br />In my experience with implementing this type of configuration, some challenges will exist:<br />- Can configuration be updated at runtime, and what's the expected behaviour (I assume this would be JSR-specific?)<br />- How are config updates managed and coordinated in a distributed (cloud?) environment<br />- Providing 'sensible defaults' is often very challenging in my opinion<br />- Hierarchy, overriding and namespace collision are also a big concern. If library developers include config in their JAR with a namespace that collides with others, how is this handled? Is the order of loading an issue?<br /><br />I'm not sure XML is the correct medium for this kind of config, and a lot of modern web frameworks have moved towards the Map/properties model, e.g. Play 2 framework (based on the Typesafe work already mentioned) and Spring Boot:<br /><br />http://www.playframework.com/documentation/2.0/Configuration<br /><br />http://docs.spring.io/spring-boot/docs/1.0.2.RELEASE/reference/htmlsingle/#using-boot-configuration-classesAnonymoushttps://www.blogger.com/profile/14427824614189918270noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-89819291694776915252014-05-17T11:00:57.635-07:002014-05-17T11:00:57.635-07:00For all of the Spring aficionados, it's worth ...For all of the Spring aficionados, it's worth having a look at the related Configuration and Profile information as starting guide on how many of us perform the type of configuration outlined in the above post: <br /><br />http://docs.spring.io/spring/docs/3.1.x/javadoc-api/org/springframework/context/annotation/Configuration.html<br /><br />There is also the PlaceHolderConfigurerSupport class that a lot of us use to perform this type of configuration: <br /><br />http://docs.spring.io/spring/docs/3.1.x/javadoc-api/org/springframework/beans/factory/config/PlaceholderConfigurerSupport.html <br /><br />I blogged last year about how I typically configure this to allow externalised config to be specified at deployment/run-time:<br /><br />http://www.javacodegeeks.com/2013/07/overriding-a-packaged-spring-application-properties-file-via-an-external-file.html<br /><br />(removed original post due to incorrect link and formatting issues)Anonymoushttps://www.blogger.com/profile/14427824614189918270noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-19757219001396103692014-05-17T10:52:41.690-07:002014-05-17T10:52:41.690-07:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/14427824614189918270noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-60572602260382199222014-05-17T06:20:17.690-07:002014-05-17T06:20:17.690-07:00Anatole,
On your request at GeeCON 2014, my feedb...Anatole,<br /><br />On your request at GeeCON 2014, my feedback is now available at:<br /><br />http://blog.arungupta.me/2014/05/configuration-jsr-javaee8-what-should-be-covered/<br /><br />Enjoy!Arun Guptahttps://www.blogger.com/profile/16061355511504961025noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-84482739615967246802014-05-16T07:24:35.558-07:002014-05-16T07:24:35.558-07:00Hi Arjan (sorry for the mispelling previously)
si...Hi Arjan (sorry for the mispelling previously)<br /><br />since my aswer is a bit lengthy, I will extend the blog above. But as said, I agree.<br /><br />Regards,<br />AnatoleAnonymoushttps://www.blogger.com/profile/08634170528353247173noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-13189089400346055812014-05-16T05:05:00.053-07:002014-05-16T05:05:00.053-07:00A true Java EE aware configuration service might p...A true Java EE aware configuration service might provide each JSR with central but some more high level services like loading deployment descriptors in various ways, with transparent resolution of overlays, includes and substitutions, but also providing an SPI where user applications can register a callback to function as an additional source for a specific deployment descriptor (like the ApplicationConfigurationPopulator in JSF, see http://jdevelopment.nl/jsf-22/#533)<br /><br />Most Java EE configuration items in deployment descriptors are backed by annotations, following the rule that XML overrides annotations when both are specified. Possibly the high-level service can provide some support for this mechanism as well.<br /><br />All in all the really low-level key-value store is absolutely needed, but something more high level really dealing with configurable deployment descriptors is IMHO also needed. Existing implementations of this concept as done by Red Hat (JBoss) and Caucho (Resin) can be taken as a source of inspiration.Arjan Tijmshttps://www.blogger.com/profile/08548593340781885396noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-38776426518366142352014-05-16T05:04:14.995-07:002014-05-16T05:04:14.995-07:00I think there are two different aspects of Java EE...I think there are two different aspects of Java EE configuration.<br /><br />What's presented here (and if I'm not mistaken is pretty much what had been presented from the get go) is essentially a default key-value store, specifically targeted for configuration purposes.<br /><br />Such a key-value store is certainly needed in Java EE. The current "standard" mechanism is a combination of context-params and env-params in web.xml, system properties etc. The fact that there are many sources each having their own API is painful. context-params are a pain since you e.g. can't easily switch them between stages and you need the ServletContext to be able to access them, but this ServletContext can not be obtained statically from everywhere.<br /><br />Key-value stores for configuration are mostly used to get values into user code. For example a setting for the "feedbackEmail" that a web app displays somewhere on the site it renders.<br /><br />Java EE itself occasionally also makes use of the same mechanism. E.g. JSF uses context-params like "javax.faces.FACELETS_REFRESH_PERIOD". In rare occasions a value can also be set via JNDI (e.g. "javax.faces.PROJECT_STAGE").<br /><br />The other aspect to Java EE configuration concerns the structured deployment descriptors and annotations, which may additionally be backed by programmatic configuration during EE startup (like adding Servlets and Filters programmatically).<br /><br />For instance the following fragment from web.xml:<br /><br /><br /> 400<br /> /WEB-INF/errorpages/400.xhtml<br /><br /><br />This is also configuration, but it's not strictly key-value based. Additionally, where the key-value store is mostly consumed by the application's user code, deployment descriptors (excluding their key-value features) are almost exclusively consumed by the Java EE platform itself.<br /><br />For this aspect of Java EE configuration things like swapping between deployment descriptors, augmenting and overlays matter. Placeholders within the descriptors and annotations (EL based or not) are also important here.<br /><br />The key-value store has a couple of existing standalone implementations. The above mentioned DeltaSpike Configuration and Typesafe config are good examples.<br /><br />The deployment descriptor aspect doesn't have any existing standalone implementations. This is not surprising, as the processing of deployment descriptors happens via very container specific code in each Java EE server, and there's no SPI or hook via which external code can provide extensions for this mechanism.<br /><br />However, various vendors like Red Hat and Caucho among others have indeed extended the deployment descriptor loading and processing mechanism and provide value added features like the above mentioned overlays and substitutions.<br /><br />In https://java.net/jira/browse/JAVAEE_SPEC-19 I called this second aspect "configurable deployment descriptors".<br /><br />What I'm seeing as a bit of an issue is that this proposed JSR still seems to be very focussed on the "key-value store" idea, but doesn't really take the "configurable deployment descriptors" idea into account.<br /><br />I'm not sure that asking each individual JSR to leverage the key-value store as they see fit is really going to work. I mean, we have had simple system properties since the beginning that could have been used to provide alternative deployment descriptors (like in the javax.jpa.persistenceUnit.[name] example above), or JNDI could have been used for that, but it never happened.<br /><br />If the umbrella EE 8 coordinates this there might be some hope of at least getting something done, but I still feel something more is needed.<br /><br /><br /><br /><br /> <br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />Arjan Tijmshttps://www.blogger.com/profile/08548593340781885396noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-48507167371891587322014-05-16T03:10:32.020-07:002014-05-16T03:10:32.020-07:00Looking at the way, Parfait uses JSR 275 http://co...Looking at the way, Parfait uses JSR 275 http://code.google.com/p/parfait/wiki/IntroductionToParfait to support monitoring systems like PCP (http://oss.sgi.com/projects/pcp/faq.html) which, originally started by SGI, many Open Source and Cloud players like Red Hat also use, you may get an idea, how JSR 363 could be used for more "semantic" configuration via the right PropertyAdapter... Typesafe tried that on a very low and vague level, i.E. supporting the "usual suspects" like "100 ms" via Java Concurrency or "3 GB" for storage, but it seems even "42 cel" (using UCUM) for a maximum temparature of 42 °C a device may still be safely operated under, won't work? ;-) Integrating JSR 363 you can define configurations in all units, the Unified Code for Units of Measure (UCUM) allows, or define your own custom unit system if required.Werner Keilhttps://www.blogger.com/profile/00760260299716734104noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-53881942924911373262014-05-15T14:27:01.452-07:002014-05-15T14:27:01.452-07:00Or, we would support EL within the configuration s...Or, we would support EL within the configuration services, which may have a similar effect...?Anonymoushttps://www.blogger.com/profile/08634170528353247173noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-7062516121837846192014-05-15T10:37:39.625-07:002014-05-15T10:37:39.625-07:00What about the ability to use EL in all Java EE de...What about the ability to use EL in all Java EE deployment descriptors (web.xml, faces-config.xml, persistence.xml, etc)<br />JBoss has an option to enable this and it works really well.Unknownhttps://www.blogger.com/profile/10663139430927586284noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-48385860716062811442014-05-15T09:47:47.343-07:002014-05-15T09:47:47.343-07:00Something else to look at, if you haven't seen...Something else to look at, if you haven't seen that is Typesafe config: https://github.com/typesafehub/config<br />The general idea seems not too different. Werner Keilhttps://www.blogger.com/profile/00760260299716734104noreply@blogger.comtag:blogger.com,1999:blog-6710986841844568686.post-87189531207872774672014-05-15T07:06:54.980-07:002014-05-15T07:06:54.980-07:00Hi
That's basically aligned with DeltaSpike C...Hi<br /><br />That's basically aligned with DeltaSpike Configuration part ( http://deltaspike.apache.org/configuration.html ). You have an utility method to be able to use it everywhere (not only CDI), an abstraction with nice defaults to read from in the app or outside and an integration with frameworks to make it easy to use.rmannibucauhttps://www.blogger.com/profile/17913242634471981420noreply@blogger.com