This is primarily a user feature to make it easier to identify a file type (by its extension). It plays no role whatsoever in how files are processed, so you should get identical build/runtime behavior whether it is a .jcs or a .java file.
For Eclipse users, it is hardly a feature, since it really wants things that contain Java source code to be named .java... so I'd certainly recommend going that route. -- Kyle On 4/14/05, Scott Semyan <[EMAIL PROTECTED]> wrote: > Since we are talking about this, why the JCS extension on the Impl > files? It's a pain to use them in Eclipse. I've renamed them .java > during editing and they seem to compile and run fine. > > Scott Semyan > > -----Original Message----- > From: Kyle Marvin [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 14, 2005 9:43 AM > To: Beehive Developers > Subject: Re: javabeans and controls > > Now that you understand the design, you can understand the impl too! :) > > Take a look at > controls/src/runtime/org/apache/beehive/controls/runtime/generator/Contr > olManifest.vm > (the Velocity template for JAR manifest generation) and I'm 100% certain > you can submit a patch along with the bug. > > All of the JavaBean codegen stuff lives in this directory, so often > fixes for codegen issues live here too... > > -- Kyle > > On 4/14/05, Mridul Muralidharan <[EMAIL PROTECTED]> wrote: > > Hi Kyle , > > > > Thanks a lot for clarifying this ! > > I will file the appropriate bugs - and this time , I dont have any > > hack to offer since I was not sure of the design intentions :) > > > > Regards > > Mridul > > > > Kyle Marvin wrote: > > > > >Mridul, > > > > > >The intention is that Controls should be 100% conformant with the > > >JavaBeans spec. You should be able to do things like: > > > > > >- load, introspect, and use the Control bean class in any JavaBeans > > >aware editor > > >- use a Control anywhere a JavaBean can be used (like <jsp:useBean> > > >JSP tag) > > > > > >If there are areas where they are not, then these should be filed as > > >high-priority JIRA issues. I checked the JAR spec, and "Java-Beans:" > > >is the correct manifest attribute, so this is definitely an > > >oversight/bug. > > > > > >Both this and the serialization issue (serializability of all > > >code-generated or supporting runtime classes is definitely a reqt > > >too) should be opened as "Critical/fix by V1" issues. > > > > > >Your Controls questions and feedback are proving to be invaluable.... > > >keep 'em coming! :) > > > > > >-- Kyle > > > > > >On 4/14/05, Mridul Muralidharan <[EMAIL PROTECTED]> wrote: > > > > > > > > >>Hi all, > > >> > > >> Since ControlBean is essentially a javabean , I wanted to see the > > >>interoperatability of controls with a pure javabean env. > > >>For this , I got the BDK1.1 > > >>(http://java.sun.com/products/javabeans/software/bdk_download.html - > > > >>yep , I know this is old !) and tried to load a simple control jar > in it. > > >>I had to modify the BDK code to also accept "JavaBeans: true" as a > > >>javabean (it had a check for only "Java-Beans" - btw , is this valid > ? > > >>Have not checked the spec yet on this). > > >>What I found was that when I try to serialize a control after having > > > >>customized it , it throws an exception indicating that it cant be > > >>serialized. > > >>On some digging I found that this was 'cos > > >>"org.apache.beehive.controls.api.properties.PropertyKey" had a field > > > >>"Method _getMethod;". > > >>Now , since Method is not serializable , this fails serialization of > > > >>the entire ControlBean. > > >> > > >>So question would be whether this is the intended behavior - as in > > >>Controls were not expected to interoperate with a plain vanilla > > >>javabean env ? > > >>(From what I have seen till now , beehive seems to go to great pains > > > >>to maintain interoperability and is not just using and riding over > > >>the javabeans framework). > > >>If it is expected to interoperate, then I guess this would be a bug. > > >> > > >>Any thoughts , comments , help would be greatly appreciated ! > > >> > > >>Thanks and Regards, > > >>Mridul > > >> > > >> > > >> > > > >
