Hi, I am having compilation problems when compiling the extensions
core. Do these missing symbols come from a version of the MyFaces
1.2.8-SNAPSHOT that is not yet present in the maven repositories?
Cheers,
Bruno
[INFO] Compilation failure
/scratch/projects/myfaces-extensions-scripting/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[25,42]
cannot find symbol
symbol : class ClassLoaderExtension
location: package org.apache.myfaces.shared_impl.util
/scratch/projects/myfaces-extensions-scripting/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[37,39]
cannot find symbol
symbol: class ClassLoaderExtension
public class CustomChainLoader extends ClassLoaderExtension {
/scratch/projects/myfaces-extensions-scripting/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[25,32]
cannot find symbol
symbol : class StartupListener
location: package org.apache.myfaces.webapp
/scratch/projects/myfaces-extensions-scripting/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[36,63]
cannot find symbol
symbol: class StartupListener
public class StartupServletContextPluginChainLoader implements StartupListener {
/scratch/projects/myfaces-extensions-scripting/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[48,18]
cannot find symbol
symbol : method
addClassLoadingExtension(org.apache.myfaces.scripting.servlet.CustomChainLoader,boolean)
location: class org.apache.myfaces.shared_impl.util.ClassUtils
2009/8/27 Bruno Aranda <[email protected]>:
> That is really excellent news! Thanks!
>
> Bruno
>
> 2009/8/27 Matthias Wessendorf <[email protected]>:
>> pretty cool!
>>
>> thanks!
>> Matthias
>>
>> On Thu, Aug 27, 2009 at 12:57 PM, Werner Punz<[email protected]> wrote:
>>> Hello everyone, here is a small bomb I am dropping, some might have
>>> noticed already by the Jira entries.
>>>
>>> This minute I committed a first preliminary working version of the
>>> Java!!! reloading code.
>>> It still is rough and has limitations, but it works already for expanded
>>> webapps.
>>>
>>> Ok here is how it goes: I basically just dynamically recompile the
>>> objects on the fly and try to save attributes of the old instance
>>> in the new one. Since JSF has introspection left and right, this works
>>> out pretty well.
>>>
>>> If you check out the web.xml of the provided example you can find two
>>> config entries which you can use to point towards your real source
>>> paths, otherwise WEB-INF/groovy and WEB-INF/java is picked up as source
>>> path.
>>>
>>> You can run after adjusting your web.xml the example via
>>> mvn:jetty-run:exploded and you can edit the provided java classes
>>> of the example (TestBean under WEB-INF/java and its dependencies)
>>> on the fly and what the code being recompiled on the fly
>>> and new adjustments being applied without server restarts!
>>>
>>> Following limitations are present for now
>>>
>>> a) Statically compiled java code can only call the dynamic one either by
>>> using introspection or by using interfaces, otherwise you will
>>> get class cast exceptions even if the classname of the dynamic class
>>> does not change (the engine sees two classes both having the same name
>>> but are different)
>>>
>>> b) You can run currently only in webapp environments (EAR for now is not
>>> fully supported) and exploded, I will work out those limitations in the
>>> long run, but for now I am happy that it even works!
>>>
>>>
>>> Happy hacking
>>>
>>> Werner
>>>
>>>
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
