Autoloader issues

[Elin Waring]

Hi,

I've been working on a platform application and I've run into a bunch of issues with the autoloader and am not quite sure what to do. This is a JWeb application and right off the top I get

Fatal error: Class 'JObject' not found in /home/owner/www/ebay/joomla-platform/libraries/joomla/filter/input.php on line 23

This is fixable by renaming the JObject class to JBaseObject but then of course we have the same issue with

Fatal error: Class 'JObject' not found in /home/owner/www/ebay/joomla-platform/libraries/joomla/environment/uri.php on line 24

Again, this is fixable by changing the reference to JBaseObject ... but then we come to w

Fatal error: Class 'JFactory' not found in /home/owner/www/ebay/joomla-platform/libraries/joomla/content/factory.php on line 22

The problem is here

https://github.com/joomla/joomla-platform/blob/staging/libraries/loader.php#L265

The way it is written since Factory has only one part we go looking or JFactoryFactory but it doesn't exist so we don't find find anything hence the fatal error.

So, I'm happy to write something for the Factory special case but I don't know if there are some plans in mind already for it. 

But for the other issues I don't want to willy nilly start renaming classes since all that is going to do is to disguise the failures by changing the inputs. In other words, I think we need to start with writing the failing tests and then change the code so the tests pass. So right off the top of my head I would say it shouldn't be a fatal error if the autoloader doesn't find something using the naming conventions but instead there should probably be a fall back to something else like checking whether something has been loaded in another way. 

Before investing a lot of time in this I'd like to hear what people think about how to handle or if someone is working on this already.

Elin

[Rouven Weßling]

On 02.02.2012, at 14:20, Elin Waring wrote:

I've been working on a platform application and I've run into a bunch of issues with the autoloader and am not quite sure what to do. This is a JWeb application and right off the top I get

The autoloader doesn't work for all classes yet. To mind come the base, environment, filesystem and utilities packages which don't work at all. There are also several classes in other packages that don't work (i.e. most of JApplication). I think the deal right now is that you have to keep using jimport for some classes.

Fatal error: Class 'JObject' not found in /home/owner/www/ebay/joomla-platform/libraries/joomla/filter/input.php on line 23

This is fixable by renaming the JObject class to JBaseObject but then of course we have the same issue with

Fatal error: Class 'JObject' not found in /home/owner/www/ebay/joomla-platform/libraries/joomla/environment/uri.php on line 24

Again, this is fixable by changing the reference to JBaseObject ... but then we come to w

Fatal error: Class 'JFactory' not found in /home/owner/www/ebay/joomla-platform/libraries/joomla/content/factory.php on line 22

The problem is here

https://github.com/joomla/joomla-platform/blob/staging/libraries/loader.php#L265

The way it is written since Factory has only one part we go looking or JFactoryFactory but it doesn't exist so we don't find find anything hence the fatal error.

Those two shouldn't happen. Are you correctly loading the import.php file before doing anything else? Both JObject and JFactory are loaded there.

So, I'm happy to write something for the Factory special case but I don't know if there are some plans in mind already for it. 

But for the other issues I don't want to willy nilly start renaming classes since all that is going to do is to disguise the failures by changing the inputs. In other words, I think we need to start with writing the failing tests and then change the code so the tests pass. So right off the top of my head I would say it shouldn't be a fatal error if the autoloader doesn't find something using the naming conventions but instead there should probably be a fall back to something else like checking whether something has been loaded in another way. 

I'm not sure what you mean here. The fatal error you're seeing are from PHP, not from out code. They simply happen because none of the (auto)loaders correctly loaded the class and thus the code can't be executed.

The autoloader itself should never throw errors since that would prevent any other autoloaders from running, this would break the CMS autolaoder for starters. Kunea also has it's own autoloader as far as I know.

Also the autoloaders aren't run at all if the class is already loaded.

I hope I could help you.

Best regards

Rouven

[Elin Waring]

It's not me that is loading these things, JApplicationWeb loads them. JApplicationWeb does not include any import.

Elin

[Rouven Weßling]

You'll have require the import.php, else not even the autoloader is set up.

Maybe you could post a short hello world examples that displays the behavior you're seeing? That would be helpful.

Rouven

[Elin Waring]

Yup  no import.php, would be great to put that into the example applications even though they don't really need it. 

Elim

[Elin Waring]

But wait, I DO have the bootstrap and the bootstrap does require the import. So time to dig a little deeper.

Elin

[Elin Waring]

So it looks like the issue was due to mixing of JImport and JLoader in JApplicationWeb. So avoiding that is a good thing to keep in mind.

Elin 

[Rouven Weßling]

That's weird since we freely mix them in the CMS. Do you have an example how to reproduce it? We may have a big problem if jimports() are broken.

Rouven

[Elin Waring]

Well it's in fact not weird.  The issues are when you create instances of other classes that don't use the autoloader from within a class that does and then those classes extend other classes that don't. jImport works okay for the first step (it will go attempt to create JURI or JLanguage, finding the file just fine) but then when it looks at what those classes extend it does not know not to run again because no instance of JObject exists  at that point, which is the check that it does (see link in my original post).  As I pointed out in my original post there is right now no way for the loader to know not to run when it is multiple steps away from the class where the Loader started. Hence it looks for things like JBaseObject or JFactoryFactory even though the appropriate files have been imported by jimport.  Loader has no way to  know that JObject shouldn't be expected to follow the rules it enforces.  However if you do JLoader::Register  you are just fine since it registers everything. 

 Remember that the CMS does not use the current platform and mainly relies on older classes and hence this issue would not come up. Well we do know that there was a problem with JRules versus JAccessRules references that also were expecting the autoloader and hence broken. https://groups.google.com/d/topic/joomla-dev-platform/wcZ0aKlBJAo/discussion  and  just using jimport would not solve. And in fact Andrew after first suggesting using jimport realized this and pointed out the need to use Jloader::Register

https://groups.google.com/d/msg/joomla-dev-platform/wcZ0aKlBJAo/3t8KcSvFWU4J. So we've been through this discussion before, but apparently not  gotten the lesson.

Elin 

[Elin Waring]

Another important thing to keep in mind is that, obviously, even if a class itself has a camel case name for readability (as opposed to autoloading) you must not use camel case when creating a new instance. JWebClient is a good example

$this->client = new JApplicationWebWebClient;

it will look in 

joomla-platform/libraries/joomla/application/web/web/client.php' (length=84)

but if you say

$this->client = new JApplicationWebWebclient;

it will look for

joomla-platform/libraries/joomla/application/web/webclient.php' (length=83)

Or joomla/web/client verus joomla/webclient/webclient
if you are using old style.

Even though the camel case names make them more readable I wonder if we should be using them since IDEs probably won't be able
to handle correctly.

Elin

[Rouven Weßling]

On 03.02.2012, at 15:04, Elin Waring wrote:

> Well it's in fact not weird. The issues are when you create instances of other classes that don't use the autoloader from within a class that does and then those classes extend other classes that don't. jImport works okay for the first step (it will go attempt to create JURI or JLanguage, finding the file just fine) but then when it looks at what those classes extend it does not know not to run again because no instance of JObject exists at that point, which is the check that it does (see link in my original post). As I pointed out in my original post there is right now no way for the loader to know not to run when it is multiple steps away from the class where the Loader started. Hence it looks for things like JBaseObject or JFactoryFactory even though the appropriate files have been imported by jimport. Loader has no way to know that JObject shouldn't be expected to follow the rules it enforces. However if you do JLoader::Register you are just fine since it registers everything.

Both JFactory and JObject are indeed registered in the import.php file. I'd be really good if you could post an example that shows the error so other can do some testing.

> Remember that the CMS does not use the current platform and mainly relies on older classes and hence this issue would not come up. Well we do know that there was a problem with JRules versus JAccessRules references that also were expecting the autoloader and hence broken. https://groups.google.com/d/topic/joomla-dev-platform/wcZ0aKlBJAo/discussion and just using jimport would not solve. And in fact Andrew after first suggesting using jimport realized this and pointed out the need to use Jloader::Register
> https://groups.google.com/d/msg/joomla-dev-platform/wcZ0aKlBJAo/3t8KcSvFWU4J. So we've been through this discussion before, but apparently not gotten the lesson.

The issue here was that people weren't importing all the classes they were using but relied on other classes importing them. When we removed the jimports() from those classes this broke because now classes are only loaded when they're actually used.

On 03.02.2012, at 17:50, Elin Waring wrote:

> Another important thing to keep in mind is that, obviously, even if a class itself has a camel case name for readability (as opposed to autoloading) you must not use camel case when creating a new instance. JWebClient is a good example

JWebClient is another example of a class that can't be autoloaded right now. My preferred solution for this class would be renaming it to JApplicationWebClient and renaming its file from webclient.php to client.php.

Best regards
Rouven

[RedEye]

> JWebClient is another example of a class that can't be autoloaded right now.
>My preferred solution for this class would be renaming it to JApplicationWebClient and renaming its file from webclient.php to client.php.

I also run in the issues Elin described, I asked myself why there are
new classes which can not be used with the autoloader, autoloader
since 11.3, JWebClient since 11.3, renaming it is so more a bugfix
than a prefered solution in my eyes :D

[Rouven Weßling]

JWebClient is certainly one of the easier cases. It should be fixed in a couple of days: https://github.com/joomla/joomla-platform/pull/828

Rouven